
Calhoun 

Iniiiiuiiortfl Arthivcof (he Navjl Pwigndualt School 


Calhoun: The NPS Institutional Archive 
DSpace Repository 



Theses and Dissertations 


1. Thesis and Dissertation Collection, all items 


1995-03 

Configuration management for expert system 
development: application to the MK92 
prototype Maintenance Advisor Expert System 

Ferrel, Tyrone H. 

Monterey, California. Naval Postgraduate School 
http://hdl.handle.net/10945/31596 

This publication is a work of the U.S. Government as defined in Title 17, United 
States Code, Section 101. Copyright protection is not available for this work in the 
United States. 

Downloaded from NPS Archive: Calhoun 



DUDLEY 

KNOX 

LIBRARY 


htt p ://w w w. n ps.e-du/l ib ra ry 


Calhoun is the Naval Postgraduate School's public access digitaI repository for 
research materials and institutional publications created by the NPS community. 
Calhoun is named for Professor of Mathematics Guy K. Calhoun, NPS's first 
appointed —and published —scholarly author. 

Dudley Knox Library / Naval Postgraduate School 
411 Dyer Road / 1 University Circle 
Monterey, California USA 93943 







NAVAL 

POSTGRADUATE 

SCHOOL 

MONTEREY, CALIFORNIA 


THESIS 


RAPID, VALUE-BASED, EVOLUTIONARY ACQUISITION 
AND ITS APPLICATION TO A USMC TACTICAL SERVICE 
ORIENTED ARCHITECTURE 

by 

Tyrone H. Ferrel 
June 2009 

Thesis Advisor: Rick Hayes-Roth 

Second Reader: Carl Oros 


Approved for public release; distribution is unlimited 




THIS PAGE INTENTIONALLY LEFT BLANK 



REPORT DOCUMENTATION PAGE 


FomTA^ro^^O/WSWa_0704^0/88_ 
Public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing 
instruction, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection 
of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including 
suggestions for reducing this burden, to Washington headquarters Services, Directorate for Information Operations and Reports, 1215 
Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-4302, and to the Office of Management and Budget, Paperwork Reduction 
Project (0704-0188) Washington DC 20503. 

2. REPORT DATE 

June 2009 


6. AUTHOR(S) Tyrone H. Ferrel 


11. SUPPLEMENTARY NOTES The views expressed in this thesis are those of the author and do not reflect the 
official policy or position of the Department of Defense or the U.S. Government._ 


13. ABSTRACT (maximum 200 words) 

Over budget, behind schedule, and underperforming information technology acquisition programs 
plague not only the USMC, but almost all government agencies and many private sector entities as well. 
Causes of this crisis abound and one cannot easily or narrowly define them because of their seemingly 
disparate and far-reaching nature. This thesis first defines what truly constitutes an acquisition program’s 
success versus its failure and then analyzes general causes of project failure, focusing on lack of both 
value and timeliness. Rapid, value-based, evolutionary acquisition (RVEA) is introduced as an improved 
acquisition method compliant with current government rules and regulations that could help reduce the 
causes of such failure. RVEA focuses on the characteristics of user-defined value, cyclic rapidity, and 
continual improvement through systematic evolution. The foundation of these attributes is 
comprehensively described in a comparison with the ideals found in the process of attaining information 
superiority. The thesis concludes with recommendations for acquisition action officers through a 
discussion of RVEA’s application to the potential acquisition of a Tactical Service Oriented Architecture for 
the USMC. 


16. PRICE CODE 


NSN 7540-01 -280-5500 Standard Form 298 (Rev. 8-98) 

Prescribed by ANSI Std. Z39.18 


20. LIMITATION OF 
ABSTRACT 


15. NUMBER OF 
PAGES 

99 


14. SUBJECT TERMS 

Acquisition, Defense Acquisition, Rapid Acquisition, Project Management, Program 
Management, Service Oriented Architecture, Tactical Service Oriented Architecture 


18. SECURITY 
CLASSIFICATION OF THIS 
PAGE 

Unclassified 


19. SECURITY 
CLASSIFICATION OF 
ABSTRACT 

Unclassified 


17. SECURITY 
CLASSIFICATION OF 
REPORT 

Unclassified 


12b. DISTRIBUTION CODE 


12a. DISTRIBUTION / AVAILABILITY STATEMENT 

Approved for public release; distribution is unlimited 


7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 

Naval Postgraduate School 

9. SPONSORING /MONITORING AGENCY NAME(S) AND ADDRESS(ES) 

N/A 


5. FUNDING NUMBERS 


8. PERFORMING ORGANIZATION 
REPORT NUMBER 


10. SPONSORING/MONITORING 
AGENCY REPORT NUMBER 


4. TITLE AND SUBTITLE 

Rapid, Value-based, Evolutionary Acquisition and Its Application to a USMC 
Service Oriented Architecture 


3. REPORT TYPE AND DATES COVERED 

Master’s Thesis 


1. AGENCY USE ONLY (Leave blank) 


I 



























THIS PAGE INTENTIONALLY LEFT BLANK 



Approved for public release; distribution is unlimited 


RAPID, VALUE-BASED, EVOLUTIONARY ACQUISITION AND ITS 
APPLICATION TO A USMC TACTICAL SERVICE ORIENTED 

ARCHITECTURE 


Tyrone H. Ferrel 

Major, United States Marine Corps 
B.S., United States Naval Academy, 1994 


Submitted in partial fulfillment of the 
requirements for the degree of 


MASTER OF SCIENCE IN INFORMATION TECHNOLOGY MANAGEMENT 


from the 


NAVAL POSTGRADUATE SCHOOL 
June 2009 


Author: Tyrone H. Ferrel 


Approved by: Rick Flayes-Roth 

Thesis Advisor 


Carl Oros 
Second Reader 


Dan Boger 

Chairman, Department of Information Sciences 



THIS PAGE INTENTIONALLY LEFT BLANK 


IV 



ABSTRACT 


Over budget, behind schedule, and underperforming information 
technology acquisition programs plague not only the USMC, but almost all 
government agencies and many private sector entities as well. Causes of this 
crisis abound and one cannot easily or narrowly define them because of their 
seemingly disparate and far-reaching nature. This thesis first defines what truly 
constitutes an acquisition program’s success versus its failure and then analyzes 
general causes of project failure, focusing on lack of both value and timeliness. 
Rapid, value-based, evolutionary acquisition (RVEA) is introduced as an 
improved acquisition method compliant with current government rules and 
regulations that could help reduce the causes of such failure. RVEA focuses on 
the characteristics of user-defined value, cyclic rapidity, and continual 
improvement through systematic evolution. The foundation of these attributes is 
comprehensively described in a comparison with the ideals found in the process 
of attaining information superiority. The thesis concludes with recommendations 
for acquisition action officers through a discussion of RVEA’s application to the 
potential acquisition of a Tactical Service Oriented Architecture for the USMC. 
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I. INTRODUCTION 


A. PURPOSE 

This thesis formulates, examines and illustrates specific principles of 
acquisition management designed to increase the probability of successful 
acquisition of Defense-related information systems. A Tactical Service Oriented 
Architecture (TSOA) for the United States Marine Corps (USMC), as a concept 
on its way to an acquisition program of record, illustrates the principles of this 
management strategy. The recommendations conveyed in this thesis have 
applicability to not only the acquisition of a USMC TSOA, but also to Department 
of Defense (DoD) Information Technology (IT) acquisition in general. 

B. OBJECTIVES 

This thesis has several objectives. Directly related to the stated purpose 
above, the primary objective suggests an improved approach to DoD acquisition 
of IT systems, using value-based logic and ready for immediate implementation 
by the Services. (Hereafter, Services with a capital ‘S’ refers to the branches of 
U.S. military services - the Army, Navy, Air Force, and Marine Corps - and the 
U.S. Coast Guard.) As a secondary objective, this thesis illustrates the 
application of this acquisition approach to a subject of direct interest to the 
USMC: Tactical Service Oriented Architecture. Additionally, in order to build 
foundational background and support for the primary and secondary objectives 
above, this thesis includes an analysis of DoD IT program success versus failure. 

C. RELEVANCE 

The topic of an improved approach for the acquisition of DoD information 
systems emerged through the research of material provided by the Marine Corps 
Systems Command in Quantico, Virginia, in its pursuit of expertise on Service 
Oriented Architectures (SOAs). In April 2008, the Marines published a request 
for information (RFI) that solicited: 
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...ideas, initiatives, and/or processes [related to the] governance, 
development, and operation of Service Oriented Architectures 
(SOA) within the United States Marine Corps at the tactical and 
enterprise levels. (FedBizOpps.gov, 2008) 

The RFI explains that the solicitation results from DoD direction (DoDD 
8320.02, 2004) to migrate legacy IT architectures to SOAs to the greatest extent 
possible and to the lowest level tactically possible. Marine Corps leadership is 
approaching this daunting task with skeptical apprehension as evident in the 
RFI’s additional statement, “...if not implemented correctly, the transition to a 
SOA will greatly disrupt operations at the tactical and enterprise level, increase 
costs, and adversely affect combat efficiency.” 

The Marine Corps and other government agencies maintain justifiable 
uneasiness in implementing a “solution” that will have effects—positive or 
negative—across the board, both on enterprise and edge (tactical) users. Failure 
in this acquisition endeavor potentially looms in the distance, and, if realized, 
failure would have lasting disruptive consequences. Improving the manner in 
which we, the DoD, develop and procure our IT systems, will reduce the chances 
of such failure. Subsequent chapters reveal sound principles for DoD IT 
acquisitions that accomplish this improvement. 

D. THESIS QUESTIONS 

This thesis focuses on IT acquisition management. As such, it aims to 
answer one primary question involving IT acquisition in the DoD and the Marine 
Corps, and three secondary questions, the first two of which help define Defense 
acquisition project success. The last secondary question relates to the 
acquisition of a USMC TSOA. The questions posed are: 

1. Primary Research Question: 

a. What are the essential principles of acquisition to 

successfully deliver valued capabilities to the warfighter? 

2. Secondary Research Questions: 

a. What defines acquisition project success and failure, and 
what causes one’s failure? 
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b. How does the concept of timeliness fit in the equation for 
acquisition value? 

c. How can the USMC apply the essential principles of rapid, 
value-based, evolutionary acquisition to the development 
and procurement of a TSOA? 
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II. BACKGROUND 


A. JUSTIFIABLE APPREHENSION 

The USMC, DoD, and businesses worldwide are approaching IT projects 
with increasing trepidation... and rightfully so. Failed IT acquisition projects 
costing investors and taxpayers billions of dollars annually litter the path to 
“improvement” much to the dismay of well-intended, experienced and 
knowledgeable project managers and executives. According to a 2005 study, 
organizations will completely abandon 5-15% of all IT projects before or shortly 
after delivery (Charette, 2005). These numbers appear optimistic when 
considering another 2005 study, which states that only 10% of 250 different 
projects reviewed successfully achieved their stated objectives for cost, schedule 
and quality (Jones C. , 2004). While the other 90% of those projects did not 
totally fail, a startling 9 out of 10 never achieved their goals! Yet another 
interesting generalization says 25% of all IT projects fail, 25% succeed, and the 
other 50% fall somewhere between success and failure (Kozak-Holland, 2007). 
These statistics vary, but they all grab our attention because of the staggering 
failure rates. Technology professionals in the public and private sector alike fully 
recognize these facts and yet the struggles continue in the area of IT project 
management and acquisition. 

The Defense Department has no immunity to this plague. Nearly all major 
defense acquisition programs today include a significant amount of software and 
IT. The Marine’s MV-22 Osprey for example contains over 10 million lines of 
code and the Joint Strike Fighter over 11 million. Without their complex suite of 
computerized flight control systems which significantly rely on IT, neither would 
fly, much less accomplish their stated missions. This complexity has contributed 
to schedule delays, cost overruns, or even program cancellation in the case of 
the Navy’s A-12 carrier-based attack aircraft (Stevenson, 2001). Not limited to 
aviation, these problems contributed to the ineffectiveness and eventual 
cancellation of the U.S. Army’s M247 Sergeant York anti-aircraft gun in 1985. 
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More currently, the Army’s highly complex Future Combat Systems program with 
its estimated 32 million lines of code struggles with increasing costs and lagging 
schedules. These types of delays, overruns, and other programmatic problems 
combined with unsatisfactory performance or flat-out system failures have led the 
U.S. Government Accountability Office (GAO) to designate the DoD systems 
development and modernization efforts as a “high-risk area” (GAO/HR-99-1, 
1999). One must ask... Why? 

B. PROJECT SUCCESS AND FAILURE DEFINED 

Before analyzing the causes of such a dismal performance record for IT 
acquisition, the context of this thesis requires a more concise definition of project 
success and failure as the terms apply to DoD systems acquisitions. Without a 
clear understanding of the meanings of the words, analysis of their causes and 
application of potential solutions stretches to impossibility. After solidifying these 
definitions, they will serve as reference points throughout the remainder of this 
thesis. 


1. Part of the Problem: A Lack of Definition of Success 

Lacking a distinct definition of success and failure, a project will most likely 
never attain and avoid each respectively. 

The big problem with assessing project success is that it is not 
precise... This dynamic can often be the Achilles heel for a project. 
Without a dependable understanding of what constitutes success, 
the project is placed in the untenable position of being judged 
against differing criteria, and invariably becomes one more failure 
statistic reported by research firms... (O'Brochta, 2002) 

The North American English Encarta Dictionary characterizes success as the 
achievement of something planned or attempted. But what exactly defines that 
“something” for an IT project? 
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IT projects typically have multiple goals and objectives. Which one or 
ones really count hinges on opinion and varies widely depending on the domain 
and the stakeholder’s position of interest within or relative to that domain. For 
instance, a performance objective of an IT project in the domain of a private 
sector business may include streamlining a process in order to increase 
efficiency. An example of such a project is the development and employment of 
an airline’s self-check-in system intended to decrease customer wait times by a 
certain percentage. This same project most likely would have internal cost and 
schedule goals for its implementation in addition to its performance goals. In the 
end, if the project runs a bit over budget and begins operation a few weeks 
behind schedule but still meets its performance objectives, upper level 
management would probably categorize it as a success, even though it did not 
meet all of its objectives. (Note the project manager however, as a different 
stakeholder may have another opinion and consider it a personal failure since 
cost and schedule goals, as his responsibility, missed the mark.) Now 
considering another outcome, if it met its budget and time objectives but failed to 
meet its performance goal to decrease customer wait times, all stakeholders 
would probably consider it a failed project. Why? Because in this case and 
others in the private sector, the reason for failure classification is often easy to 
understand: “Success for the commercial world is straightforward and simple: 
maximize profit.” (GAO-06-110, 2006) Private sector businesses conceive 
projects in order to improve the bottom line, through either cutting costs or 
increasing revenue, and a business would most likely not consider a venture 
project unless it has the potential to generate positive returns. 1 In our example 
above, the likely intent of the airline self-check-in system might include improving 
the customers’ experience, resulting in repeat business, which would in turn 
increase revenue. Or perhaps the company intended to reduce the number of 


1 This is an intentional oversimplification and not intended to convey that all businesses are 
purely self-promoting entities that do not participate in other worthwhile activities that might not 
necessarily generate profit. Examples of these activities include those which improve public 
image, improve employee health, contribute to worthy community or charitable causes, etc. 
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employees behind the check-in counter, which would decrease costs. Either 
way, both of these desired results affect the company’s financial bottom line, 
which truly determines success or failure upon completion of a commercial 
project. 

Unfortunately, project success in a public sector organization such as the 
Defense Department eludes such clear definition, and this fact leads to problems. 
Taking a simplistic view when comparing DoD to commercial systems 
acquisition, success’s definition initially appears similar: deliver a product that 
meets the requirements, on time and for the right price. Further investigation, 
however, reveals the implied definition for success at least in the DoD 
complicates the matter. Often a program’s ability to attract funds for itself and 
other projects defines success, instead of the program meeting any real 
objectives. Project managers on both the government and defense contractor 
sides accomplish this through overly optimistic cost and schedule estimates or by 
avoiding or delaying reports of bad news that might decrease a program’s 
funding line (GAO-06-110, 2006). The figure below shows a comparison of 
commercial project success versus DoD project success and the resulting 
behaviors as reported by the GAO. 
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Commercial companies 

DOD 

Success 

Sale to customer. 

Attracting funds. 

Means to 
success 

Strategic planning/prioritizing. 

Competition for funds. 


Realism and candor. 

Optimism and unknowns. 


Early testing. 

Late testing. 


Early redllghts, greenllghts based on 
demonstration. 

Early greenllghts; late redllghts. 


Collaboration and trust. 

Oversight and distrust. 


Senior leaders are program 
advocates. Corporate research 
departments are technology 
developers. Program manager Is 
executor. 

Program manager Is often the 
advocate, technology developer, 
and executor. 


Single program manager Is 
accountable for delivery. 

Multiple program managers are 
accountable for continuation. 


Source: GAO. 


Figure 1. Differences in Definition of Success and Resulting Behaviors 

(From GAO-06-110) 

According to the Under Secretary of Defense for Acquisition, Technology 
and Logistics, "... the enterprise will often pressure acquisition teams and 
industry to provide low, optimistic estimates to help start programs.” (Young, 
2009) These overly optimistic cost, schedule and performance estimates 
ultimately hurt any program because the eventual application of realistic 
estimates reveal a program unexpectedly in a cost overrun, behind schedule and 
failing to meet performance objectives. This sometimes occurs when a program 
commences its critical early stages. If a program survives such a disadvantaged 
initiation, it most likely will produce a sub-par performing system in the hands of 
the end user - the warfighter in tactical domain of the DoD. Nevertheless, was 
this program a success? Unlike the commercial world, a simple measurement of 
profit or loss does not answer this question. Nor does the ability of the project to 
“stay alive” and continue attracting funding support determine success. Instead, 
value delivered to the customer determines the true success or failure of a 
tactical DoD system. 
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2. DoD Acquisition Program Success vs. Failure 

The warfighter who ultimately will use a tactical system wants that system 
to contribute to his or her mission. The ability of that system to contribute value 
to the warfighter’s task defines success for that class of stakeholders. Thus, 
value delivered by that system equates to success. The system can contribute in 
many different ways. Perhaps it lightens a load, improves communications 
ability, increases decision-making effectiveness, or improves survivability. Since 
the warfighter considers value-adding systems or products successes, one 
should, by the same token, consider the projects or programs which developed 
and procured them successful. Similarly, the warfighter also determines project 
failure. If a fielded system improves no aspect of a warfighter’s job, it fails. This 
judgment of failure depends not on coming in over budget or behind some 
arbitrary programmatic schedule. Instead, it rests on the system not satisfying 
user-defined quality attributes on the user’s timeline. Simply stated, if the system 
does not provide value to the warfighter when needed, it and the program 
responsible for its development and procurement both fail. 

This does not imply the warfighter is the only stakeholder in a tactical 
system. On the contrary, we must recognize the fact that every American from 
the top down retains some interest in such a project. For instance, the U.S. 
Congress allocates a program’s funding and measures its ability to remain on 
schedule and on budget. The DoD and its associated projects sometimes 
directly or indirectly employ the constituents of these Congressmen and women. 
The program management team and responsible contractors have interests in 
seeing their program reach operational status. And of course, the American 
taxpayers, in support of national defense, provide funding for all DoD projects. 
As rightful stakeholders, these people all share valid inputs, concerns, and 
interests, but they do not determine the success or failure of a program. 
Ultimately, only the end user—the warfighter—can declare true success or failure 
of a tactical system. 
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The first increment (Block 1) of the Target Location, Designation and 
Handoff System (TLDHS) illustrates a warfighter’s determination of success vs. 
failure. The system boasted innovative and impressive capabilities as it allowed 
a Forward Air Controller to precisely determine the location of a target and 
digitally send this location to a Close Air Support (CAS) aircraft overhead for 
prosecution. These features minimized voice communications and consequently 
decreased the chances of miscommunication. Unfortunately, the warfighter (the 
FAC) did not value Block 1 of the system because it lacked usability. Because of 
its weight and bulk, warfighters found it difficult to carry. They also had trouble 
reading its display in sunlight. Its magnetic compass made it impossible to use 
near vehicles. Additionally, it required a lengthy and involved setup process that 
included multiple cables, attachments, and a slow processor boot up. Because 
of these and other limitations, the user did not value the system. Its lack of 
usability far outweighed the benefits it offered in locating targets and minimizing 
communications, and without necessarily saying so, the warfighters considered it 
a failure as just another 40 lbs. of gear they had to carry and account for. 

The many qualitative and quantitative definitions of project success and 
failure both in the private and public sectors vary widely. In the business of 
warfighting though, the definitions break down into relatively simple terms: 
success = value added for the user; failure = no value added. 

C. WHY DO DOD IT SYSTEMS FAIL TO SATISFY THE WARFIGHTER? 

With firm definitions of project success versus failure, this section will 
examine some of the causes of such failure. It will first review some of the more 
universal causes of project or program failure and then narrow the scope to look 
at the challenges faced by the government, specifically DoD, acquisition 
programs and why they fail to deliver user-valued products. 

1. Causes of “Failure” Abound 

Using a more generic definition of project failure than the warfighter’s 

described above, IT projects fail for a number of different reasons or combination 
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of reasons. Various organizations and experts have analyzed this subject for 
decades and their studies usually produce lists of factors that contribute to 
project failure. A 1994 Standish CHAOS Report concluded the following as top 
factors in failed projects (Frese & Sauter, 2003). Although almost 15 years old, 
this list preserved comprehensive and relevant points that still contribute to 
project failures today. 

• Incomplete requirements 

• Lack of user involvement 

• Lack of resources 

• Unrealistic expectations 

• Lack of executive support 

• Changing requirements and specifications 

• Lack of planning 

• Project no longer needed 

• Lack of IT management 

• Technical illiteracy 

Other contributors not listed in the report deserve at least mentioning. For 
example, developers often inadequately understand user needs (Field, 1997) or 
the users poorly communicate their needs to the IT development team (Hoffman, 
2003). Additionally, information system projects often take place in an 
environment characterized by the following, “[a] lack of management continuity 
and an incentive system that encourages overly optimistic estimates of the 
benefits that can be attained from doing the project.” (Hulme, 1997) 

Acquisition programs in the DoD are simply projects (albeit far from simple 
though) and as such involuntarily expose themselves to failure due to the above 
causal factors. Unfortunately, DoD projects face those obstacles as well as 
many others not typically encountered by private industry. Considering the 
organizational size and complexity of the DoD and the defense industry, the 
following factors additionally challenge the success of their IT projects. 
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• Inter-Service rivalry and competition 

• Lack of personnel continuity (GAO-08-782T, 2008) 

• Ill-responsive requirements and budget process (GAO-08-782T, 
2008) 

• Dislocated, uninformed and disinterested user community 

• Inexperienced or unqualified acquisition workforce (GAO-08-1159T, 
2008) 

• Event-driven projects executing a time-driven budget 

• Onerous oversight via rules, regulations and reporting requirements 
(GAO-06-110, 2006) 

• Numerous integration and interoperability requirements 

• Risk and change averseness 

• Failure averseness (inability to dismiss sunk costs) (GAO-08-379, 
2008) 

• Lack of user training 

• Lack of post-deployment support 

• Self-gratifying and inappropriately motivated incentive system 
(GAO-08-782T, 2008) 

• Overly optimistic cost and schedule estimates (GAO-06-110, 2006) 

2. Why Do Projects Fail to Provide Value to the User? 

The lists above offer some insight into the causes of generic project 
failure. Narrowing the scope of this analysis, consider the warfighter’s definition 
of failure as described in the preceding sections. Using that definition, why would 
a project fail, or more precisely, why would a system not deliver value to the 
user? The reasons logically divide into two broad categories: either (1) some 
aspect of the system does not provide value to the user or worse, hinders the 
user, or (2) the system did not meet the user’s required timeline. 

a. Causes of Failure - System Aspects 

The first category is relatively simple - the intended user finds no 
satisfaction due to a shortfall of the system relative to their needs or desires. 
These user goals cover a broad spectrum of system requirements related to its 
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performance and physical characteristics, such as usability, reliability, 
transportability, maintainability, etc. Inadequacies in these areas contribute to 
project failure because they devalue the system in the eyes of the user. 
Obviously, different levels of consequence exist in this category. On one 
extreme as an example, the system burdens more than benefits the user and as 
a result, it actually decreases the warfighter’s effectiveness and retains no value 
whatsoever. At the other end of the spectrum, the system takes on some, but 
not much value. An example of this could include a lack of organizational 
support for a decent system because of inadequate training or spare repair parts. 
These relate to a failure of some aspect of the system itself, and they all reduce 
the value the user places on it, thereby increasing its chance of ultimate failure. 

b. Causes of Failure - Lack of Timeliness 

The second category of contributions to tactical IT project failure is 
more abstract than the first, but it cripples a project just as much, if not more so. 
These factors relate to the speed at which value reaches the user. Before the 
1990s, system design used a traditional waterfall approach or a single step to full 
capability (SSFC). This process identified a capability gap; developed an item to 
fill that gap; built, tested, fielded it and subsequently supported it for the next few 
decades until the product reached its end and required replacement. This slow 
process worked well for hardware intensive systems where the identified 
capability gap, or target, stayed relatively stationary and immune to technological 
volatility. Programs did not rush to complete the project because the target 
remained when the piece of hardware rolled off the production line. For example, 
the legacy military Jeep and its replacement, the High Mobility Multi-purpose 
Wheeled Vehicle (HMMWV) well illustrate this. The acquisition target, or desired 
capability of lightweight vehicular transportation, persisted throughout the 
HMMWV’s development and production, and was therefore relatively easy to hit. 
Ultimately the users valued the product because the requirement defined in 1981 
remained valid through system delivery in 1985 and beyond. The program hit the 

target and the military considered it a success. 
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However, since then software has assumed many functions 
historically accomplished by hardware. IT now permeates most military systems, 
and as a result, the SSFC method of acquisition has become less appropriate. 
Today, the target no longer cooperates by remaining stationary because of the 
rapid rate of technological change. Timeliness of acquisition has pervaded its 
way into the equation for project success. Using a slow, inflexible process to 
develop and produce an IT system likens to taking slow, methodical aim at a 
distant, randomly moving target. This equates to a kiss of death for an IT project 
because of the target’s seemingly unpredictable movements, and the system will 
never succeed in its aim. By the time the system achieves delivery, the target 
has changed and the user will not value it (e.g. it fails) for multiple reasons. The 
paragraphs below provide details on some of these reasons. 

(1) Project No Longer Needed. Determining a formal 
requirement for a DoD acquisition program requires time, sometimes years. The 
Joint Capabilities Integration and Development System (JCIDS) process provides 
the means to “ensure the joint warfighter receives the capabilities required to 
successfully execute the missions assigned to them” (CJCSI 3170.01 F, 2007). 
Unfortunately, this process takes an exorbitant amount of time and requires 
numerous approvals before finalization of a formal requirements document. The 
requirement feeds the Defense Acquisition System, which translates the desired 
capability into an acquisition program (DoDI 5000.02, 2008). 

The time required to develop and produce a system varies 
greatly depending on a number of different factors including the system’s 
complexity, technological maturity, and the number of stakeholders, to name a 
few. Throughout this prolonged process of identifying a requirement, acquiring 
program funding, developing and finally producing a system, the requirement 
likely will change... possibly due to an environmental or technological change or 
any one of a number of other reasons. As a hypothetical example, a radio 
frequency jamming device intended to counter wirelessly detonated improvised 
explosive devices (lEDs) becomes operational after insurgents have switched 
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tactics and now detonate their lEDs using some other means. The user views 
the jammer as irrelevant and unsuccessful even though it may effectively jam 
detonation signals. Due solely to its tardiness, the system fails because it 
burdens users as yet another item they have to account for, train on, maintain, 
transport, store, etc. In these situations, no system at all provides more value 
than a late system. As General James Cartwright, the Vice Chairman of the Joint 
Chiefs of Staff said, "It takes longer to declare a new [program] start than the 
lifecycle of the software package." (Boessenkool, 2009) Rapid change truly 
marks the information age, and slow-developing IT systems often reach users 
only to fail in satisfying recently changed or invalidated requirements. The user 
does not need the tactical system provided and disappointment results. The 
system fails. 

(2) Event-driven Projects Executing a Calendar-driven 
Budget. The Planning, Programming, Budgeting and Execution System 
(PPBES) requires a calendar-driven sequence of events while the DAS follows 
an event-driven schedule (Jones, McCaffery, & Fierstine, 2005). This means 
DAS programs must demonstrate increasing maturity and readiness as they 
approach eventual fielding. These programmatic demonstrations, defined very 
early in a program’s lifecycle, occur as readiness reviews and milestones and 
require formal approval by the milestone decision authority. As a technologically 
intensive system proceeds through the DAS, beneficial innovations sometimes 
allow them to accelerate their schedule and potentially provide a capability to the 
warfighter sooner than expected. However, the PPBES, inflexibly calendar- 
driven in nature, does not allow for such change and requires a program to 
remain on schedule as technological innovations come and go. As Mr. Robert 
Carey, the Navy’s Chief Information Officer (CIO) said in a recent interview, 

Things are moving really fast. The acquisition system, and more 
importantly the budgeting system, moves at a different pace... 

Today, if most of you come in and say, 'I've got this great idea. I 
want to give it to you,' all of our money has been displaced... There 
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is little agility in that system. When you go spend it on something 
else, an opportunity, you generally have to break something else.” 
(Boessenkool, 2009) 

More common than an opportunity to accelerate though, is 
the occurrence of some problem in the process causing a schedule delay or an 
inability to execute its budget. The PPBES not only discourages such change, it 
effectively punishes it through a use-it-or-lose-it mentality. In other words, if a 
program cannot execute funds before they expire, it will probably lose those 
funds to a program that can execute them. As an additional consequence, it will 
have a much harder time justifying keeping its funds in future years. This 
inflexibility can have a compounding negative effect of spiraling a program into 
further delays, which allows mainstream technological capabilities to outrun the 
program’s original requirements until the first bullet above comes to fruition: the 
need for the project disappears and it ultimately fails to deliver anything of value 
to the user. 

(3) Lack of Personnel Continuity. The USMC has 

recognized the importance of a qualified acquisition workforce and strives to 

better support it through the creation of new military occupational specialties 

(MOS), continuing education, and centers of excellence. These efforts, 

respectable as they are, do not solve the personnel continuity problem in the 

acquisition community though. USMC Manpower and Reserve Affairs requires 

military members to continue duty rotations every three years. If a workforce 

member arrives at his acquisition command, new to military acquisitions and 

unfamiliar with its vocabulary, organizations, and requirements, it will take about 

a year before he or she effectively contributes to a program. During this action- 

officer learning time a program seldom advances as quickly and effectively as it 

would with an experienced acquisition professional at the helm. Although hard to 

justify one person holding an entire program back, when that program 

encounters personnel changes continuously, negative effects inherently 

accumulate and the program suffers. Furthermore, considering the slow pace of 

military acquisitions where three years might encompass only a single phase of a 
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program’s procession through the DAS, the program may potentially have 
multiple managers and project officers throughout its lifecycle, each of whom 
requires separate, time-consuming learning curves. Because of this fact, the 
program’s institutional memory and tacit knowledge constantly and quickly fades; 
lessons learned go undocumented and subsequently require relearning, further 
challenging any programmatic advancement. This discontinuous knowledge 
limits a program’s progress and schedule delays result, both of which can lead to 
eventual project failure. 

(4) Onerous Documentation, Regulations and Reporting 
Requirements. Although the DAS encourages streamlining the acquisition 
process, its efforts fall short of the efficiency and speed necessary to exist as a 
viable means to procure IT systems. On the surface, the DAS instruction 
appears to support flexibility, which logically improves the process. But the 
numerous statutory and regulatory requirements levied upon even small 
programs render the process anything but easy. The tables in the DoDI 5000.02 
reveal the documentation required for a program offering a mature technology to 
enter the process at, for example, Milestone C (Production and Deployment): 14 
different statutory requirements and 26 regulatory requirements... 40 different 
documents, all of which require review and approval up a hierarchical chain of 
command. The generation of such a mound of paperwork and its subsequent 
approval do not happen overnight. In fact, the process takes months or 
sometimes years. Although the documentation requirements arguably intend to 
protect the American taxpayer from wasting money on failed acquisition 
programs, they often have the opposite effect, further delaying an already slow 
process to a point where the user no longer values the end product. 

The four categories above illustrate how a program can fall victim to 
the numerous time taxes and distracters that delay system delivery to the user. 
In the information age, the value a warfighter places on a specific solution stales 
quickly, so any delays in the provision of that solution lead to decreased value 
and can spell eventual failure for the system and its associated program. Speed 
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increases value; likewise, lateness provides little value. This cause of failure due 
to a lack of acquisition timeliness defines the second of two broad categories 
discussed, the first being system-specific causes of failures. One other 
contributor to DoD IT project failure does not fit neatly into either category, but 
deserves mentioning here. It relates to the operator’s perception of military 
acquisitions. 

Warfighters unfamiliar with the acquisition world typically hold a 
negative view of DoD acquisitions... and for good reason. They identify 
operational needs for the acquisitions process and sometimes participate in the 
formal requirements generation events or user juries. But seldom during their 
current tour (typically about 3 years) will they actually see a system go from 
inception to successfully operational, satisfying those needs. This unfortunate 
fact again occurs due to the typically slow and unresponsive acquisition process. 
The users maintain sad awareness that, for reasons mostly unknown to them, it 
takes years to define, develop, test, and deploy a system in the DoD. This 
awareness combined with the dissatisfaction from inadequate support plans for 
many existing systems has led to a distrustful attitude on the part of the user 
community that greatly contributes to prejudices against new systems. Sarcastic 
phrases such as “drive-by fielding” or “another ‘fine’ product from Systems 
Command” evidence this cynicism. Failures of new systems sometimes spiral 
into self-fulfilling prophesies due to these types of prejudices. The user declares 
the new system a failure before ever giving it a fair chance at success. 

When these perceptions and prejudices apply to an IT-intensive 
system highly susceptible to technological progression laws such as Moore’s, 2 
Butter’s, 3 and Kryder’s, 4 the user’s negative view of military acquisitions 


2 Gordon Moore’s Law states that the number of components per integrated circuit doubles 
every 24 months (ComputerHistory.org, 2007). 

3 Gerry Butter’s Law states that the amount of data we are able to transmit through an optical 

medium doubles every 9 months (Robinson, 2000). 
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entrenches even more firmly. In the deployment phase of the acquisition cycle, 
the user receives IT systems that often incorporate obsolete technology, usually 
due solely to the slow speed of the acquisition process. Furthermore, the user 
has a keen awareness of the system’s obsolescence because today’s 
warfighters, as members of the information generation, maintain a solid grasp on 
the technological trends of the day. They unfortunately judge the performance of 
military systems against the commercial systems found on the shelves of their 
local electronics retailer and in such comparisons, the military systems fall short 
every time. Simply put, the warfighter values the availability of current 
technology and objects to the provision of old technology. This again illustrates 
the value of a timely acquisition process. 

A better means of acquisition—a more agile, responsive process 
that focuses on providing incremental value to the user in rapid succession— 
could greatly lessen the negative impacts of some of these factors contributing to 
user dissatisfaction and project failure. This holds especially true for IT 
acquisition projects subjected to both obsolescence and constantly changing 
targets. Using the previously stated definitions of success and failure, delays 
greatly exacerbate the impacts of most of the above causal factors and 
effectively push projects closer to failure. On the other hand, decreasing the so- 
called time to market followed by rapid, iterative improvements will increase 
value and, consequently, the program’s chances of success. Considering these 
observations, the acquisitions process in the DoD needs rapid, value-based, 
evolutionary acquisition. 


4 Mark Kryder’s work involves analyzing the impacts of exponentially increasing bit 
storage capacity relative to physical component size, and he hypothesized that magnetic 
disk areal storage density doubles annually (Walter, 2005). 
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III. RAPID, VALUE-BASED EVOLUTIONARY ACQUISITION 5 

Throughout history, environmental changes have caused adaptive 
adjustments in the methods and management techniques used by organizations 
to develop and produce items. Organizations realized a need for improvement 
and they adjusted their methods accordingly. For example, the increasing 
complexity of systems along with an expanding environment in the mid-1900s 
gave rise the discipline of systems engineering (Hall, 1962). Project 
management illustrates another example of such an adjustment. Although 
practiced for centuries, its formalization as a discipline did not occur until the 
1950s when managers saw a need to approach projects from an integrated 
perspective, methodically accounting for complexities between cost, schedule 
and performance of systems (Cleland & Gareis, 2006). Most recently, the past 
two decades have witnessed a dynamic shift in the commercial sector’s ability to 
produce technologically superior products compared to the military. Historically 
sought after because of its toughness and rigorous Military Specification 
(MILSPEC) standards, the equipment of the defense industry previously 
pioneered technological advancements, and commercial applications of the 
innovations typically followed. But the market’s insatiable demand for the cutting- 
edge capabilities stimulated a role reversal. Private industry assumed the 
military’s role as technological pioneer, and the latest products, after proven 
commercially, seek applications in the military (Alberts, Garstka, & Stein, 1999). 
Furthermore, the military has increasingly less influence on the private sector 
because of its declining share of the IT market as shown in Figure 2 (Stogdill, 


5 The name, Rapid, Value-based, Evolutionary Acquisition (RVEA), is mostly credited to 
Chris Gunderson, David Minton and Rick Hayes-Roth from their whitepaper entitled, “Value- 
Based Acquisition: An Objective, Success-Centric, Evolutionary Approach.” Although this 
approach has other additional attributes, this thesis emphasizes its rapid, value-based, and 
evolutionary nature as its three most important qualities, and therefore coins the name RVEA. 
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1999). In a reactionary effort to take advantage of these commercially 
developed, technologically mature items, the DoD conceived evolutionary 
acquisition (EA). 



Figure 2. Military's Integrated Circuit Market Share (From Stogdill) 

EA, in policy, proposed an improvement in military acquisition because it 
allowed development of capabilities in increments, as opposed to forcing the use 
of the traditional waterfall method. Additionally, the DoD instruction implementing 
EA declared it as the “preferred” acquisition method and theoretically provided 
flexibility to procure mature technologies relatively rapidly, instead of requiring full 
procession through development, engineering, and testing (DoDI 5000.02, 2008). 
EA looked like, at least on paper, a step in the right direction to account for yet 
another environmental change. 

A. THE REQUIREMENT FOR RVEA 

The DoD created EA for relatively simple reasons: react to environmental 
factors of (1) increasing systems complexity and the related requirement for 
better planning, and (2) increasing demand for flexibility and rapidity. Certainly, 
the pressures that spawned systems engineering, project management, and EA 
as illustrated above pertain today. Continual improvement necessitates further 
adjustment beyond simple EA in order to optimize our response to these forces. 
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As mentioned, the DAS prefers EA as its acquisition method in policy, and 
at first glance considering the enlightening language of some of the acquisition 
regulations, one might believe EA contains the sought-after improvement 
sufficient to improve acquisition effectiveness. After all, it sounds good on paper, 
but according to the GAO, DoD has yet to implement true evolutionary 
development in practice (GAO-06-110, 2006). The GAO uses the Joint Strike 
Fighter as an example of a current program attempting to provide too many 
significant capability improvements in a single step rather than providing 
incremental improvements in capabilities over time. Such overly ambitious 
capability leaps inevitably result in schedule delays, neglecting the importance of 
timeliness (providing value to the user as quickly as possible). Additionally, 
attempting to provide a 100% solution predictably causes other problems such as 
cost overruns and considerable interoperability challenges. Although the DoD 
has recognized the requirement for an evolutionary acquisition method and 
attempted to implement it in policy, in actuality the process still desperately 
needs improvement. 

Another evolutionary environmental force alive and well today relates to 
our dependence on IT, and considering the ambitious goals of defense systems 
now compared to only a few years ago, this dependence will only increase. 
Combine our escalating dependence with the dismal success rate of information 
systems projects described in a previous section, and most of the high 
aspirations for information systems supporting national defense will probably 
never materialize... unless we find and implement a better means of acquiring 
those systems. 

B. THE FOUNDATION OF RVEA 

National defense today demands harnessing the power of information. 
Our highest leaders have recognized information’s strategic and tactical 
importance (DoD Information Management and Information Technology Strategic 
Plan, 2008-2009) as evident in concepts such as full spectrum dominance, 
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information/net-centric operations and warfare, systems of systems, and the 
Global Information Grid, to name a few. These concepts aspire to improve 
decisions largely based on information. It therefore makes sense that 
possessing better information and processing it more effectively and efficiently 
than the enemy will lead to better, faster decisions, which in turn will produce 
better outcomes. Joint Publication 3-13 calls this ability Information Superiority: 
“The operational advantage derived from the ability to collect, process, and 
disseminate an uninterrupted flow of information while exploiting or denying an 
adversary’s ability to do the same” (Joint Publication 3-13, 2006). 

Militaries cannot accomplish information superiority overnight, nor can 
they achieve it and then forget about maintaining it. Instead, information 
superiority embodies a position that our forces must first deliberately attain, and 
then, just as important and perhaps more difficult, effectively maintain and 
exploit. Gaining and holding a superior information position requires a highly 
effective process of continual improvement, staying a step ahead of the enemy 
by focusing on value and speed... a process in which information systems 
technology has become a critical enabler. 

Coincidentally, the process of achieving information superiority has many 
noteworthy similarities to the process we should use to develop and procure its 
supporting technologies and ultimately provide value to the user. Three of these 
similarities—value-based, rapid, and continual improvement—form the 
foundation of RVEA and the following sections describe the qualities of this 
process, pointing out similarities with the process of attaining information 
superiority. 

1. Value-based 

The book, Network Centric Warfare, states that exploitation of a superior 
information position results in a competitive advantage, which in turn creates 
information superiority. The book goes on to say that the “creation of value is at 
the heart of creating [this] competitive advantage.” (Alberts, Garstka, & Stein, 
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1999) The information collected, communicated and exploited in attaining 
information superiority therefore requires value. Without value or meaning, 
information merely contributes to info-glut and clouds situations, increasing the 
fog of war, which consequently decreases combat effectiveness (Hayes-Roth, 
Model-based Communication Networks and VIRT: Filtering Information by Value 
to Improve Collaborative Decision-Making, 2005). 

One cannot discuss the concept of information value without also 
mentioning how value is determined, or more appropriately, who determines 
value. Decision-makers and operators define the value of information based 
upon its ability to contribute to their knowledge of a situation, and their input 
therefore determines what information to filter or forward. Imperative here is who 
defines value: not the system developer or administrator of the filter mechanism; 
instead, the decision maker decides value. Operational commanders as 
decision-makers practice this concept routinely by defining commander’s critical 
information requirements. 

While the process of achieving information superiority relies on the 
production of valued information, an acquisition process must similarly produce 
valued operational products. As described in the previous section defining 
project success and failure, the user of such a product measures value in terms 
of its ability to improve his or her job, just as the user of information defines its 
value based upon how it improves their decisions. For this reason, user 
involvement rises to an essential level in the acquisition process... not only the 
requirements definition phase, but also the system’s development, testing and 
beyond. Employing users in this manner first ensures value as an objective and 
second confirms a system’s ability to provide that value. Likewise, neglecting 
user input at these critical points will lead to the developer assuming what 
defines user value, and the system will likely miss the mark, which will certainly 
contribute to the project’s ultimate demise. 
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2. Rapid 

The pace of life continues to accelerate. Each decade, the speed required 
for achieving success markedly increases. Society demands swiftness for the 
reporting of news, weather, market quotes and other types of information 
because the value of that information decreases over time. We, as members of 
society, also require the ability to instantly and remotely communicate with each 
other, and technology allows us to do so through email, text/instant messaging, 
etc. The relatively high speed these capabilities offer assists in making us more 
knowledgeable and efficient than without them. 

Warfare also moves at a more rapid pace today than in previous decades, 
and combatants sometimes win battles because of an ability to achieve and 
exploit a superior information position partially due to rapidity. Capitalizing on a 
superior information position requires timeliness or speed for two reasons. First, 
we must collect, analyze, act upon information, and then repeat the process 
more quickly than the enemy can. Boyd called this “getting inside the 
adversary’s OODA loop.” (Boyd, 1986) Originally applying this concept to air 
combat maneuvering (ACM) in the Korean War, he won visual aerial combat 
engagements, or dogfights, by observing, orienting, deciding and acting 
(completing the OODA loop) repetitively faster than his opponent could. This 
technique eventually placed him in an advantageous position that he capitalized 
on in the form of weapons employment. Boyd captured this technique in his 
writings as a military strategist and it has since seen application to larger-scale 
competitions, including gaining a strategic advantage in modern conflicts such as 
Operation Desert Storm in 1991 (Cowan, 2000). Possessing a faster decision 
cycle contributes to one’s ability to achieve and exploit information superiority. 

The second reason speed matters greatly for information superiority 
derives from the perishability of information. The longer information sits 
unattended, the staler it becomes. In war, this fact results primarily from the fast 
rate of change of the battlespace. Operational forces have the same demands 

as society for current—as close to real time as possible—information because it 
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quickly stales, especially in wartime. Old information often equates to inaccurate 
information due to an unobserved change in the situation, and it seldom 
produces optimal decisions because of this inherent inaccuracy. In fact, no 
information is usually better than inaccurate information because, lacking 
information concerning a situation, commanders will make typically conservative 
estimates, fully realizing they cannot accurately grasp the situation’s reality. 
Whereas unknowingly using inaccurate or stale information gives rise to 
suboptimal or even wrong decisions. Commanders therefore, just like society, 
require current information in order to increase their knowledge and efficiency, 
effectively improving the quality of their decisions in pursuit of information 
superiority. Rapid observation and analysis of a situation followed by quick 
decisions and actions form key enablers of this ability. Bottom line: speed 
increases value. 

Speed also translates into increased value in the acquisition process for 
reasons similar to those above in attaining information superiority. The ability to 
observe, orient, decide and act more quickly than our opponent allows us to get 
inside his loop and achieve a competitive advantage. Likewise, we must get 
inside the loop of our opponent in the acquisition process, but on the acquisitions 
battlefield the enemy lurks as both external and internal forces. Externally, the 
current enemy is the same as in the Global War on Terror, a wily and quickly 
adaptive adversary not bound by acquisition rules and regulations or even the 
Geneva Conventions. His weapons include lEDs and suicide bombers, and only 
their imagination and budget limit their capabilities. Internally however, the 
enemy resides within a slow acquisition process which cannot cope with a rapidly 
changing environment, and it wields weapons of technology obsolescence and 
changing requirements. 

Focusing on the internal enemy, the acquisition cycle time, or loop, must 
operate faster than the forces of obsolescence and requirements change, both of 
which devalue a system in the eyes of an operator, just as time decays and 
devalues information supporting an operational commander. To quantify this 
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concept, obsolescence occurs constantly, but in general, commercially available 
technology’s planned lifecycles survive only about 18-24 months, paralleling 
Moore’s Law (Beck, 2003). Requirements changes follow a similar, albeit less 
predictable pattern, influenced by factors such as the global security 
environment, adversary’s capabilities, and technological advancements. RVEA 
should therefore strive to provide an operational capability within no more than 2 
years after deciding upon a particular technology. The risk of not doing so could 
easily result in fielding an obsolete or unnecessary system. 

Denning, Gunderson and Hayes-Roth articulate the significance of a short 
acquisition cycle time: 

Development time is the critical factor. This is the time to deliver a 
system that meets the requirements set at the beginning of the 
development process. If development time is shorter than the 
environment change time, the delivered system is likely to satisfy its 
customers. If, however, the development time is long compared to 
the environment change time, the delivered system becomes 
obsolete, and perhaps unusable, before it is finished. In 
government and large organizations, the bureaucratic acquisition 
process for large systems can often take a decade or more, 
whereas the using environments often change significantly in as 
little as 18 months (Moore’s Law). (Denning, Gunderson, & Hayes- 
Roth, 2008) 

Figure 3 illustrates this problem by depicting a desired increase in capability over 
a few years. A system using a single step approach (top graph) or even a 
lengthy incremental evolutionary approach (middle graph) risks missing the 
target primarily because of the prolonged time to value. The question marks on 
the graphs indicate the uncertainty involved in aiming at a distant, randomly 
moving target. The long-term requirements freeze many years before planned 
delivery. This early target determination occurs too prematurely to estimate (1) 
exactly how requirements will change or (2) what new technological innovations 
will arise over the course of those years, either of which stand to lessen the value 
of or even nullify the system in the operator’s opinion. The bottom graph depicts 
the alternative, which provides value to the user in much shorter increments than 
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the middle graph, and then repeats, effectively allowing continual retargeting, as 
opposed to risking missing a long-range, potentially infeasible target defined 
years earlier. 6 





Figure 3. Desired Capability vs. Time. The progression of charts from top 
to bottom illustrate different approaches to managing acquisition, 
ranging from a “ballistic” attempt to deliver desired capability in a 
single cycle to a rapid adaptive approach with multiple short cycles 


6 The graphs in Figure 3. are adapted from a classroom discussion from Dr. Hayes-Roth’s 
Information Systems Strategy and Policy at the Naval Postgraduate School. 
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continually re-aimed toward the next target of incrementally 
improved capability. (From Hayes-Roth) 

Expanding on Boyd’s ACM analogy, the tactical aircraft saying, “Speed is 
life!” further illustrates the value of rapidity. Fighters require high 
maneuverability, and lacking sufficient speed, they cannot maneuver to attack or 
defend. In aerial combat, bleeding airspeed is relatively easy, but opportunities 
to gain airspeed in the visual arena seldom occur. For this reason, possession of 
a speed or energy advantage creates a competitive advantage over the enemy. 7 
Alternatively, in a visual air-to-air engagement if a fighter pilot finds himself 
excessively slow against an opponent who has and maintains an energy 
advantage, the opponent will eventually gain an offensive position because of his 
superior maneuverability and kill him. In an air-to-ground mission requiring 
reaction to enemy air defenses, speed is essential for the same reason; a lack of 
speed effectively makes an aircraft unable to defend against surface-to-air fires. 
Similarly, we can usually slow down an acquisition process, but seldom can we 
speed it up once started. Additionally, if we do not maintain the speed of an 
acquisition process, producing valued systems inside our adversaries’ loops, 
they—the enemies of obsolescence or requirements change—will render our 
product value-less and the program will eventually fail. 

Continuing the aerial combat analogy, as an additional benefit, speed 
increases options. With a sufficient speed advantage, a fighter aircraft has 
multiple options from which to choose that translate into a competitive 
advantage, such as exchanging knots for nose position to employ weapons or 
converting excess kinetic energy into potential energy by climbing to establish an 
altitude sanctuary from which to attack or escape an opponent. In contrast, with 
a speed disadvantage an aircraft really has only one option: try to increase 


7 This logic purposefully over-simplifies the value of high speed in an ACM engagement. The 
author recognizes the significance of cornering speed and the fact that an offensive aircraft can 
easily be “too fast” in some situations such an impending overshoot. The author also recognizes 
the value in other situations of slow speeds, such as when attempting to force an opponent’s 
overshoot. 
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kinetic energy by descending while also trying to stay alive. Similarly, the quicker 
we provide a valued capability to the user, the more rapidly we can analyze our 
new situation relative to the enemy (including technological opportunities and 
operational requirements), capitalize on any successes, and apply them to our 
future objectives, effectively shortening our cycle time while providing more 
options. Alternatively, a prolonged acquisition process only has one option: 
continue towards long term and perhaps outdated requirements or face 
termination. 

Accomplishing our objectives requires a rapid process, whether in pursuit 
of information superiority, in a dogfight, or in acquisitions. Intuitively, possession 
of a faster process than the enemy directly contributes to successful operations 
and consistently provides more options from which to choose. Again, the bottom 
line: Speed increases value. 

3. Continual Improvement 

Achieving a competitive advantage necessitates continual improvement, 
and once we achieve it, sustaining that position requires the same consistent 
focus on continual improvement. In an effort to accomplish this, military Services 
use feedback mechanisms to improve upon past military operations in the form of 
lessons learned, after action reports, case studies, and general military history. 
We teach and study such documentation in an effort to retain and convey our 
predecessor’s knowledge. For example, the Marine Corps has recognized the 
value of a feedback mechanism through the creation and staffing of its Center for 
Lessons Learned, which strives to capture operational experiences in an effort to 
improve future operations and exercises. 

Achieving information superiority also requires a feedback mechanism to 
support continual improvement. This mechanism involves validation of multiple 
facets of information in order to realign future actions toward an end goal. This 
process requires an established methodology to capture and analyze not only 
previous actions taken, but also the effects resulting from those actions. In his 
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book, Hyper-Beings, Dr. Hayes-Roth emphasized the importance of an effective 
feedback mechanism to enable adaptive behavior and facilitate improvement 
(Hayes-Roth, 2006). Referencing Figure 4, the last step of his eight-step 
superior decision loop is Validate and Improve the Model. Although the model 
defines it as the last step, it occurs not only at step eight, but throughout all steps 
of the loop, which forms the essence of continual improvement. Applying his 
model to the achievement of information superiority, while focusing on step 8, we 
see that we must continually validate and improve upon the following facets of 
information: 

• Which information provides value 

• How we get that information 

• How we analyze it 

• How we use it to change our behavior 

• How we communicate it 
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The Superior Decision Loop (From Hayes-Roth) 


RVEA must similarly incorporate continual improvement. EA, although an 
acquisition policy improvement as defined in the DoD Instruction 5000, does not 
effectively incorporate feedback or focus on continual improvement. To its credit, 
it mentions spiral development in which we develop a little, test a little, develop a 
little more, test a little more, but it does not stress the importance of establishing 
a methodology to improve upon each spiral over time. EA, as opposed to RVEA, 
does not necessarily capitalize on what works and kill what does not. Instead, it 
takes the results of a spiral - whether successful or not - and attempts to fix it or 
add functionality to it, inevitably increasing its complexity and consequently 
decreasing its evolvability (Sangwan, Lin, & Neill, 2008). In order to keep this 
complexity in check and continue focusing on valued improvements, a program 
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office cannot allow a casual validation and improvement process; on the 
contrary, it must ensure a documented, formal methodology. 

Additionally, EA prematurely plans increments and spirals in a system’s 
lifecycle. For instance, it illustrates a version of so-called continual improvement 
that shows three planned increments over fifteen years with preplanned product 
improvements every five years. This is too scripted and inflexible! A program 
office must incorporate a more responsive process that captures dynamic, 
constantly moving targets and quickly provides multiple options from which to 
choose, implement, and improve on. 

Furthermore, lacking such a process that incorporates continual 
improvement will, sooner or later (probably sooner), decrease the value of even 
the most valued system because of the rate of change of requirements and 
technology. In other words, as the operators increasingly value, or perhaps more 
appropriately, covet systems they do not have, their current system’s relative 
value decreases... unless we continually validate and improve upon the current 
system. As mentioned earlier, users value current technology and object to old 
technology. 


Similar to the process of attaining information superiority, an acquisition 
process that incorporates continual improvement must strive to validate and 
improve different aspects of the process as well as the product. Unfortunately, 
the DAS encompasses multiple levels of a large hierarchical organization and 
one cannot overstate its complexity. As Dr. Hayes-Roth points out though, 

Regardless of how many levels of hierarchy, all intelligent entities 
operating in dynamic environments have to adapt their behavior 
continuously in response to feedback. The entity as a whole uses a 
decision loop to do this, and each subordinate entity in the 
hierarchy uses a decision loop in its own area of responsibility. 
(Flayes-Roth, 2006) 
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The entities could be as large as our National Command Authority (NCA) 
that sets vision and strategy, or as small as an acquisition program office 
charged with implementing an acquisition plan. Improving the acquisition 
process as it relates to the NCA is not the purpose of this thesis, so narrowing 
the broad scope of potential areas for continual improvement, subordinate 
entities such as the program office and program manager must continually 
validate and improve the following items to effect continual improvement: 

• What acquisition items provide value 

• How we develop and procure them 

• How well we are progressing toward providing value 

• How we should change our behavior to improve value delivery 

Notice the emphasis on value in the above list as a focal point for continual 
improvement. Once we implement a process based on value, we will become 
engaged in a process of continuous improvement (Hayes-Roth, Blais, Pullen, & 
Brutzman, 2008). 

Sometimes our validation and feedback process may reveal a need for a 
significant direction change. We cannot fear such change and we must address 
it forthrightly. For example, an environmental change may completely invalidate 
a requirement for a system, and the program may require termination. In order to 
effectively implement continual improvement, the acquisition process cannot shy 
away from such change or fear writing off sunk costs. It benefits all stakeholders 
to stop development of an unwarranted system instead of continuing to mount 
expenses through the unnecessary production, fielding and support of such a 
system. According to the GAO, sunk costs should not drive the decision to 
continue a program (GAO-08-379, 2008). Continual improvement means making 
occasionally tough but intelligent decisions. Although these decisions may 
sometimes displease certain stakeholders, an effective acquisition process 
hinges on them to a large degree. 
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Finally, two caveats relating to continual improvement deserve attention. 
First, an effective process of continual improvement does not warrant setting 
unjustified or haphazard strategic targets simply because of the ability to improve 
upon them later. Initial goal setting requires deliberately calculated, insightfully 
visionary, and ambitious but feasible targets. An organization cannot 
overemphasize the importance of this step. The existence of an effective 
feedback loop and improvement method should not serve as an insurance policy 
or safety net for bad strategic decisions. Second, continual improvement does 
not mean continual change. An organization with an effective method of 
accomplishing continual improvement should not consequently encourage 
continual change. On the contrary, an effectively planned vision, strategy and 
policy should minimize the frequency of major changes... even in the name of 
continual improvement. 

To summarize, rapid, value-based, evolutionary acquisition’s foundation 
rests on the principle of quickly providing user-defined value in rapid succession 
while focusing on continual improvement. These three traits—rapid, value- 
based, and continual improvement—form the basis of an effective acquisition 
process. The actual implementation of RVEA includes the same phases as 
contained in the DoD’s instruction for the operation of the DAS and aligns with 
that regulatory document. The next section details the specific actions and 
intents of RVEA throughout each DAS phase. 

C. THE OPERATION OF RVEA 

With the firm establishment of a conceptual foundation of rapid, value- 
based evolutionary acquisition, this section will concentrate on its tangible 
application. It strives to avoid abstractions, difficult to implement in the real world 
of acquisitions, and instead focuses on pragmatic, readily executable 
recommendations for a Program Management Office (PMO) or Program 
Executive Office action officer... where the proverbial rubber meets the road. 
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1 . 


Introduction 


This section briefly describes the underlying assumptions and constraints 
of the application of RVEA. Additionally, it includes descriptions of the most 
applicable documents that govern the defense information systems acquisition 
process. 


a. Assumptions and Constraints 

Government policies and regulations naturally resist change. Even 
if an established rule obviously and admittedly needs change, rescinding or 
modifying it presents quite a challenge. For example, the DoDI 5000 took years 
to update, and when the Defense Department finally published the revision in 
December 2008, it included surprisingly minimal changes, considering the time 
required for revision. This thesis therefore does not suggest improving the 
acquisition process through changes in acquisition policy. Such change would 
take too long, and whether the regulations need major revision is actually 
debatable. The process needs help now, and any improvement must operate 
under the constraints of all currently applicable regulations, directives, and 
instructions. 

The prescription to heal the problems with the DAS implies 
widespread cultural change, but one cannot realistically believe any single 
person or organization could implement a DoD-wide or even Service-wide culture 
shift with the urgency required. The culture of government and DoD acquisitions, 
deeply rooted in stove-piped, I’ve-got-mine mentalities and self-promoting, get- 
your-own rice-bowls, will not change overnight. However, breaking these bad 
habits and the desired broad cultural change begins with individuals and their 
successes, which eventually spread throughout organizations, resulting in the 
desired change. This change can and must begin with the individual action 
officers of acquisition programs. In the words of Gandhi, “You must be the 
change you wish to see in the world.” 
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b. Governing Documents 

The phrase “governing documents” encompasses numerous 
statutory and regulatory items which control the DoD acquisition process. Some 
of these items include Instructions and Directions, the Federal Acquisition 
Regulation (FAR), and various laws such as the Information Technology 
Management Reform Act of 1996 (aka the Clinger-Cohen Act or CCA). These 
documents define the rules of the acquisition process. The subsections below 
briefly describe some of the Defense acquisition’s primary governing documents 
for information systems in order to first provide the reader an appreciation for the 
rules under which acquisition action officers must operate, and second to point 
out some of the encouraging, positive aspects of these documents. Additionally, 
the description of the DoDI 5000.02 will lay a framework for the subsequent 
discussion of the application of RVEA. 

(1) DoDI 5000.02 - Operation of the Defense Acquisition 
System. The DoDI 5000.02 establishes 

a simplified and flexible management framework for translating 
capability needs and technology opportunities, based on approved 
capability needs, into stable, affordable, and well-managed 
acquisition programs. (DoDI 5000.02, 2008) 

The document’s basis lies in governance-by-exception 
where, unless specifically prohibited, an action is allowed as long as it proves 
itself appropriate, justified and does not violate another regulation. This 
encourages innovation and attempts to avoid stifling so-called thinking out of the 
box. The instruction discourages the application of additional restrictions from 
the DoD Services and Components and allows waivers to its guidelines unless 
prohibited by statute. It provides lists of all statutory and regulatory requirements 
for the lifecycle of an acquisition program, and contains sections which describe 
Acquisition Categories and determination of Milestone Decision Authority, IT 
considerations, Systems Engineering, Resource Estimation, as well as other 
subjects directly pertaining to defense acquisitions. 
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The first part of the instruction, divided into applicable 
sections, details the procedures of the phases of the acquisition process as 
depicted in Figure 5. Material Solution Analysis (aka Pre-Milestone A), 
Technology Development, Engineering and Manufacturing Development (EMD), 
Production and Deployment, and Operations and Support comprise the phases 
of defense acquisition and typically describe the life-cycle phase of a program. 
Notice, however, the three broad phases in the lower portion of the diagram: 
Pre-System Acquisition, System Acquisition, and Sustainment. These will serve 
as categories for the application of RVEA in subsequent sections. 
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Figure 5. The Defense Acquisition Management System (From DoDI 

5000.02) 


(2) Federal Acquisition Regulations System. The 
government established the Federal Acquisition Regulations System for the 
codification and publication of uniform policies and procedures for acquisition by 
all executive agencies of the U.S. Government, and the FAR is the primary 
document of the system. An enormous document with Volume 1 stretching to 
almost 2,000 pages, the FAR, not unlike the DoDI 5000.02, takes a govern-by- 
exception approach. It provides regulatory guidance for the purchase of products 
and services, and most of its parts contain at least some applicability to systems 


39 




















acquisitions. In the context of this thesis however, only certain parts of the FAR 
will be mentioned, particularly Parts 1, 7, 12, 13, 34, and 39. The paragraphs 
below paraphrase these specific FAR parts relevant to this thesis (Federal 
Acquisition Regulation, 2005). Notice the bold italicized words (formatting added 
for emphasis). 

- Part 1 - Federal Acquisition Regulations System. If a 
particular strategy or practice is neither specifically addressed in the FAR nor 
prohibited by law members should not assume it is prohibited. Rather, teams 
should interpret absence of direction as permitting innovation. 

- Part 7 - Acquisition Planning. Agencies shall perform 
acquisition planning and conduct market research for all acquisitions in order to 
promote and provide for acquisition of commercial items and for full and open 
competition to the maximum extent practicable. 

- Part 12 - Acquisition of Commercial Items. Agencies shall 
acquire commercial items or nondevelopmental items if available to meet the 
needs of the agency. 

- Part 13 - Simplified Acquisition Procedures. Prescribes 
simplified acquisition procedures in order to reduce administrative costs, 

promote efficiency and economy in contracting, and avoid unnecessary 
burdens for agencies and contractors. 

- Part 34 - Major Systems Acquisition. Ensures agencies 
acquire major systems in the most effective, economical, and timely manner. 
Agencies acquiring major systems shall promote innovation and full and open 
competition and sustain effective competition between alternative system 
concepts and sources for as long as it remains beneficial. 

- Part 39 - Acquisition of Information Technology. When 
developing an acquisition strategy, contracting officers should consider the 
rapidly changing nature of information technology through market research 
and the application of technology refreshment techniques. (Note that as National 
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Security Systems, most DoD systems would fall under Title 40 United States 
Code, Section 11302, instead of the FAR Part 39.) 

Considering the phrases emphasized above, the FAR 
means well and encourages innovation, efficiency, and rapidity. RVEA embraces 
these characteristics and brings them to the forefront of acquisition as 
measurable qualities. 

(3) Clinger-Cohen Act. The CCA mandated the 

establishment of goals for improving the efficiency and effectiveness of agency 
operations through the effective use of IT. Additionally, the CCA sought to 
prescribe performance measurements for executive agency IT and ensure these 
performance measurements determine how well the IT supports agency 
programs (The National Defense Authorization Act, 1996). 

Flaving briefly described some of the documents governing 
the acquisition process, the next section will prescribe recommended 
improvements for the process using RVEA within the bounds of these 
documents. 

2. Operation of RVEA 

Although the DoDI 5000.02 defines the commonly referred to phases of 
the acquisition process from Pre-Milestone A to Operations and Support, this 
section employs the broader activity phases of Pre-System Acquisition, System 
Acquisition, and Sustainment to describe the specifics of RVEA. 

a. Pre-System Acquisition 

Many tasks and activities must be accomplished prior to the start of 

a new acquisition program of record, and many do not directly involve acquisition 

action officers, per se, because of the top-down nature of the requirements 

generation system called JCIDS (reference Figure 6 below). Through the JCIDS 

process, top-level military officers of the Joint Requirements Oversight Council 

(JROC) identify capabilities required to support national strategies such as the 
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National Defense and National Military Strategies. Specifically, the JROC 
identifies (1) the capabilities and operational performance criteria required to 
execute missions successfully; (2) the shortfalls in existing systems to deliver 
those capabilities and the associated operational risks; and (3) the possible 
solution space for the capability shortfalls. This process supports acquisition by 
providing validated capability needs and associated performance criteria as a 
basis for acquiring the right systems, and it provides prioritization and 
affordability advice (CJCSI 3170.01 F, 2007). For the purposes of this discussion 
on Pre-System Acquisition, we will assume the JCIDS process has first 
determined a valid requirement for a materiel solution to fill a capability gap, and 
second, has ruled out all non-materiel solutions. 
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Because of the long-range nature of national strategies, the 
capabilities and technologies required to achieve these distant targets similarly 
only exist in the distant future. Reflecting back on the discussion of setting near- 
term goals for capability improvement (Figure 3. ), a program should hit the 
target, or achieve the desired capability within two years if at all possible. This 
does not suggest the JCIDS process should stop identifying long-range strategic 
capability gaps using its top-down requirements generation. On the contrary, a 
coordinated and integrated effort across the DoD necessitates the top-down 
process in its support of national strategy. But once a capability gap and an 
appropriate materiel solution are identified, the assigned program manager 
should develop an acquisition strategy that strives to satisfy the most valued 
portions of the requirement in rapid, short incremental improvements as opposed 
to attempting to fill 100% of the gap through a prolonged development phase. 
Case in point: the Joint Strike Fighter (GAO-06-110, 2006). Instead of trying to 
provide a new airframe with all new capabilities and improvements across 
multiple venues, it should have focused on providing the most valuable, most 
needed capabilities first. In other words, if the highest priority capability 
hypothetically focused on a stealthy airframe to replace the aging F/A-18, AV-8B, 
and F-16 aircraft, then to the maximum extent possible, it should have 
concentrated on providing just the airframe as quickly as possible while reusing 
preexisting, non-developmental items to accomplish other functions as long as it 
remained beneficial to do so. If at the time, opportunities existed to grab other 
low-hanging fruit (mature, demonstrated and affordable technology 
improvements) such as a more capable radar, targeting system, or data link, then 
by all means, the program rightfully should include those upgraded components 
in the first increment with the new airframe. But if those items forced delivery 
delays of the highest priority capability, i.e., the airframe, the program office 
should have pushed them to future increments. This would assist in fulfilling the 
requirement for rapid delivery of a high-value capability improvement. 
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If a technology falls short in availability or maturity which 
consequently prohibits its use to fill a valid requirement, the science and 
technology (S&T) field should justifiably assume the responsibility of developing 
and maturing that technology. It should not transition to an acquisition program 
of record (again reference Figure 6. above). Furthermore, development of any 
immature technologies by S&T should take an evolutionary, survival of the fittest 
approach to determine successes. Preferably using commercial-off-the-shelf 
(COTS) technology, this approach should investigate as many parallel competing 
alternatives as possible to satisfy the requirement and quickly determine which 
ones succeed and which ones fail. The process should then capitalize on the 
successful options and continue the cycle, modeling the technology’s 
development after the previously discussed Superior Decision Loop in order to 
provide continual improvement to not only the product, but also the process. 
(Acquisition programs of record cannot accommodate this type of developmental 
approach which investigates multiple options at a rapid rate because of the fiscal 
and programmatic constraints under which they operate.) Once a technology 
demonstrates military utility and an ability to satisfy a valid operational 
requirement in S&T though, it should quickly transition to an acquisition program 
office to confirm and/or improve upon its operational suitability and to develop 
production plans. Indeed, the Pre-System Acquisition efforts of an acquisition 
program office should focus on ensuring the suitability of readily available, 
demonstrated technologies for military use and move away from prolonged 
development of transformational or revolutionary products which attempt major 
capability leaps. This will keep programs from experiencing predictable delays of 
unpredictable duration. 

In the Pre-System Acquisition phase, following identification of a 
requirement for a materiel solution to fill a capability gap, activities must involve 
the end user in order to help guarantee the value basis of the acquisition. As 
described previously, the user stakeholder defines the value that helps ensure 
program success. The activities of this phase requiring user involvement include 
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program reviews such as the System Requirements Review which succinctly 
define the operational requirements, including Key Performance Parameters 
(KPP), Key System Attributes (KSA), and system specifications, among others. 

Excellent acquisition action officers prove their worth at these 
program meetings because when user representatives help define a system’s 
requirements, they often neglect to specify things they consider common sense 
due to a culture barrier between them and the developers. For instance, 
reflecting back on TLDHS, the users who helped define the initial operational 
requirements for the system may have never thought they had to explicitly 
specify the system’s usability in direct sunlight, and the early developers could 
have easily neglected to test the beta system anywhere except in sterile 
conditions. An acquisition action officer must anticipate challenges such as 
these and bridge the culture gap between the system designers/engineers and 
the users to ensure that all significant assumptions become explicit and no 
requirement stones remain unturned. 

Additionally, operators and developers of a system do not 
necessarily speak the same language (figuratively speaking) and an action 
officer must sometimes serve as an interpreter in defining and prioritizing a 
system’s quality aspects—usability, reliability, availability, maintainability, 
transportability, etc. Using a clearly defined and prioritized list of quality 
attributes based upon user inputs and understood by managers and developers, 
these three different stakeholders can identify tradeoff points and select the 
system functions providing the biggest bang for the buck. This prioritized list of 
functions and attributes will serve as a basis for the program’s plan for 
incremental improvements. User involvement helps ensure the value-basis of a 
system, and proactive acquisition action officers augment the meaningfulness, 
clarity, and thoroughness of the user’s inputs and help prioritize among many 
potential valued features. 
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The responsibilities of an acquisition action officer do not end there. 
He or she must define a means to measure the above qualities of the acquisition 
process, because, in the words of Drucker, you get what you measure (Drucker, 
2001). Measures of effectiveness (MOEs) have historically seen use as 
performance metrics of systems or products, but in RVEA, program offices must 
measure not only aspects of the product, but also the acquisition process itself. 
Some attributes of the process such as time to value (rapidity) are relatively 
straightforward to measure. Others, such as value and continual improvement, 
are more abstract and potentially subjective and therefore benefit from 
managerial insight and expertise. 

Arguably, the value of the acquisition process directly relates to the 
user-defined value of the end product. An action officer has the means at his or 
her disposal to measure product value. The simplest of these merely tests the 
ability of the system to meet the defined operational requirements, usually in the 
form of KPPs and KSAs. Assuming the validity and currency of the system’s 
requirements, developmental test and evaluation and operational test and 
evaluation (OT&E) measure a system’s performance in terms of reliability, 
maintainability, speed, and so forth. They consequently also measure the value 
of the acquisition process to a limited extent. An action officer should not, 
however, blindly assume the currency and validity of the system’s requirements. 
He or she should formally and informally survey user representatives throughout 
the acquisition phases to reaffirm the value of the product and process. A formal 
survey should allow the user representatives to quantifiably answer (for instance, 
on a scale of 1 to 10) questions such as: 

• If the system meets all operational requirements, what is the 
likelihood you would use it for its intended mission? 

• How many alternatives can you think of for accomplishing 
the system’s mission? How many of those alternatives 
would you more likely use instead of the system? 
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• How adequate do you consider the planned delivery 
timeline? 

• How much value do you think the planned follow on system 
increment(s) will add? 

Such formal surveys can succumb to the dangers of subjective 
biases and preconceived notions from the users though. Therefore, in order to 
qualify survey results, informal, non-retribution discussions between the users 
and the action officers about the system and its capabilities should supplement 
formal surveys. To narrow the culture gap and assist in cross pollination 
between developers and users, open discussions, preferably between these 
uniformed military members (users and action officers), will help determine the 
reliability of formal surveys. Such discussions will capitalize on an unspoken 
trust between uniformed members and help circumvent the military’s unfortunate 
but often present distrust of contractors. Additionally, an acquisition action 
officer should poll as many user representatives as possible to increase the 
reliability of such surveys. Although these surveys will not necessarily pinpoint 
problems in specific system requirements, they will give a program office an 
overall idea of the value the operators place on the system. Surveys that reveal 
a widespread lack of user value for a product highlight problems for not only the 
system under development, but also the potentially broken process as well. 

Surveys can help subjectively measure the performance of the 
acquisition process, but program offices should strive to take a more objective 
approach as well. Objectively measuring an acquisition process’s ability to 
provide continual, valued improvement does not occur easily, but Chris 
Gunderson and others at the World Wide Consortium for the Grid (W2COG) 
have taken a systematic, objective approach and devised algorithms for 
measuring not only the value basis of an acquisition process, but also its ability to 
provide continual improvement. Similar to the way the KPP of Operational 
Availability (A 0 ) measures reliability or Quality of Service (QoS) by dividing 
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successful operating time by total time to give a percent value, 8 their first 
algorithm conceptually compares the amount of valued information delivered by 
the system and available to its users against the amount of total information 
delivered or processed (reference Table 1. below). This formula equates to 
Information Value Availability, or A iv , a system-level MOE, and measures Value 
of Service (VoS) in terms of the information a system delivers/processes. The 
next algorithm factors time into the equation by determining Net-Ready 
Availability (A nr ). A nr , a process-level metric, measures Value of Enhancement 
(VoE) by calculating how well the process continually delivers valued 
enhancements to the system, taking into account the process’s originally 
estimated and current build-time performance. 9 In summary, these metrics 
effectively and objectively measure how much value each increment adds to the 
process (Gunderson, Minton, & Hayes-Roth, 2009). 


System Reliability 

A 0 = Successful operating time / Total time 

Value of Service 

A iv = Available valued bits / Total bits processed 

Value of Enhancement 

Anr = Initial estimated development time 

Capability deployment time 


Table 1. Conceptual Reliability, VoS, and VoE Algorithms 


The numerous Pre-System Acquisition activities lay the framework 
for a program’s future and, if accomplished in a manner consistent with the 
principles of RVEA, they can increase the probability of a program’s success. 
The processes of this phase, including but not limited to requirements 
generation, technology development and establishment of an acquisition 
strategy, must focus on rapidity, stand on user-defined value, and ensure 

8 This admittedly oversimplifies the operational availability algorithm and the author 
recognizes that Ao employs Mean Time Between Failure (MTBF), Mean Time to Repair (MTTR), 
and Mean Logistics Delay Time (MLDT), such that: Ao = MTBF/(MTBF+MTTR+MLDT). 

9 Gunderson, et al., have done extensively detailed analysis to capture the value-added 
performance of the acquisition process objectively in terms of time-to-capability and value of 
service, and the algorithms described here are purposefully kept at a conceptual level. As of this 
writing, their analysis was still ongoing, and this conceptual description is only a sampling of their 
efforts but sufficient for the purposes of this thesis. 
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continual improvement. Furthermore, these qualities must translate into 
measurable quantities that provide meaning to an acquisition program office. 
Successfully accomplishing these objectives in a program’s infancy will help 
ensure continued success in subsequent acquisition phases. 

b. System Acquisition 

System Acquisition technically begins with a program’s approval of 
Milestone B and its subsequent entrance into the EMD phase (reference Figure 5 
above). The DoDI 5000.02 emphasizes the importance of demonstrating a 
potential solution’s critical technical elements (CTEs) in a relevant environment 
before considering the solution a viable alternative. It further states that a 
technology’s maturity shall determine the path through EMD (DoDI 5000.02, 
2008). Within this statement lies a program’s ability to accomplish rapid 
acquisition of a capability and quickly provide value to the user: “...a 
technology’s demonstration in a relevant environment and its level of maturity...” 

An acquisition program’s ability to complete the EMD phase rapidly 
depends on the level of readiness or maturity of the proposed technology. Given 
a demonstrated, proven technology, the primary engineering effort of this phase 
should be limited to systems integration, including bundling of capabilities and 
functions, and production or manufacturing preparation. Unfortunately, many 
programs successfully meet the exit criteria of the Pre-System Acquisition 
Technology Development phase while still immature, with major engineering and 
development efforts remaining. But how is this possible considering the criteria 
to exit the phase and enter EMD, which state that, among other things, a 
potential solution must demonstrate its technology in a relevant environment? 
Similar to the aforementioned GAO findings of optimistic cost and schedule 
estimates leading to problems, acquisition programs and commercial vendors 
can take the optimistic route and purposefully decrease the rigor of 
demonstrations or the relevancy of the environment in order to “pass” 
Technology Development and enter EMD. This has the effect of making the 
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technology appear more mature than it actually is - a fact that sometimes 
materializes months or years later when schedules have slipped and cost 
estimates have escalated. To avoid this predicament of getting bogged down in 
EMD, the acquisition action officer must remain true to the warfighter and require 
rigorous and valid early demonstrations of the CTEs. Relevant demonstrations 
not only help expedite completion of EMD, but they also can factor into MOEs 
that will help a PMO objectively determine a system’s ability to provide value. 

Excessive optimism and subjective measurements of a 
technology’s maturity can ultimately lead to schedule delays, whereas stressing 
valid technological maturity has the potential to increase acquisition’s speed and 
success rate. Objective MOEs again come into play here as a system proceeds 
through the EMD phase in preparation for eventual operational testing, 
production and deployment. Applying algorithms such as those for VoS and VoE 
above will help enable a program office to measure the maturity and value of a 
technology as it attempts transition from Pre-System Acquisition to System 
Acquisition. Furthermore, to maintain awareness of the validity of the product 
and the effectiveness of the process, a program office should routinely apply the 
algorithms until its official requirements document formally adopts them as part of 
a system’s KPPs or KSAs. 

A program typically completes its Preliminary Design Review (PDR) 
and Critical Design Review (CDR) in the System Acquisition phase (although 
sometimes it may complete PDR in the Pre-System Acquisition phase), and 
emphasis on these reviews has increased in the latest update to the DoDI 
5000.02. Such reviews formally establish and confirm a system’s underlying 
architecture. Correctly designed, the system architecture should promote 
continual improvement through an evolvable, flexible and open framework that 
will readily accept rapidly changing components. Additionally, the architecture 
framework should shy away from proprietary capabilities and components and 
instead concentrate on commonality, which will encourage reusability and agility. 
These features will pay dividends when developing the manufacturing process, 
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when requirements change, and when future increments take shape. 
Furthermore, they promote continual improvement and should be built into a 
system from day one, upon initial architecture definition. Assuming a program 
has intelligently designed its system architecture which is formalized at PDR and 
confirmed at CDR, it should possess an inherent ability to continually improve 
upon the product. 

The PDR and CDR also can help a program sustain its value basis. 
Similar to the activities of requirements definition and Pre-System Acquisition, the 
source of this value stems not surprisingly from user involvement. The DoDI 
5000.02 calls for the presence of user representatives at the PDR, but does not 
explicitly require their involvement at the CDR. Programs can and occasionally 
do get side-tracked in development between PDR and CDR and as a result 
sometimes seem to confuse system priorities, which is another reason an 
acquisition action officer should never blindly assume the currency or validity of a 
system’s requirements. He or she should constantly strive to gather user inputs 
at not only these formal reviews, but also user events such as OT&E and Live 
Fire Test and Evaluation. User input is essential at PDR, CDR and throughout 
the System Acquisition phase and into the Sustainment phase. The acquisition 
action officer cannot depend on the users to provide such input; instead, he or 
she must proactively seek it. 

One word of caution though: a program should not chase a user’s 
rapidly changing requirements. Admittedly, the requirements target will always 
change or move somewhat, but program success requires at least relative 
requirements stability. Reflecting back on the enemies of obsolescence and 
changing requirements, “relative” stability means the time-to-capability must fall 
inside the time it takes the users to significantly change requirements. Even 
though the user community’s desires or needs may have shifted slightly through 
a system’s development, if a program maintains an ability to provide a valid 
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product or capability in a short timeframe, e.g., inside the internal enemy’s loop, 
the user will probably value the system, despite the slight change in 
requirements. 

Unfortunately, the DoD regulations consider a “short timeframe” 
equal to about five years for a weapon system (DoDI 5000.02, 2008), which is an 
unacceptable amount of time. Technology and user needs could easily change 
drastically in five years. For instance, imagine user involvement at a CDR for an 
IT program after five plus years of development, trying to satisfy roughly seven 
year old requirements. Two possible outcomes of user involvement in such a 
slow process will transpire: either (1) the users will deem the requirement still 
valid, and they will walk away disgruntled because of the incomprehensible 
schedule delays in the program, or (2) the now invalid requirement will cause the 
user to not understand why the program continues unnecessarily wasting money 
and time on the system. Either way, the results increase the operating force’s 
distaste for the acquisition process and reemphasize the need for rapidity and 
continual focus on user-defined value through the System Acquisition phase. 

c. Sustainment 

As the acquisition process winds down into the Sustainment phase 
and a system nears apparent completion, one might think the ability of a PMO to 
influence the process through RVEA also comes to a halt. However, this could 
not be further from the truth. The entire RVEA process emphasizes continual 
consciousness of value and improvement, but the Sustainment phase possesses 
the most logical mechanism for continuing value-addition and improvement in 
rapid fashion. The owners of the newly fielded systems have an opinion of the 
product and the process, and the program office merely has to capture this input 
and incorporate appropriate changes. 

In the Sustainment phase, systems roll off the production line and 
eventually land in the hands of users in operational units. An acquisition action 
officer should liaise continuously with these units and users to maintain 
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awareness of how or if the operators use the system. All too often, a PMO 
delivers a new system and provides initial operator training without ever 
attempting to learn from user experiences. Unadulterated user input during this 
introduction to the system can provide invaluable insight into areas worthy of 
potential improvement. Often the PMO wrongly holds an attitude of finality, and 
responds to user recommendations by saying, “The system is what it is and it’s 
not going to change until the next increment five years from now.” This 
unfortunate outlook promotes further customer dissatisfaction and gives meaning 
to cynical phrases such as drive-by fielding. 

Opportunities exist beyond the initial fielding to gather user input as 
well. The operational unit accepting a new system will most likely be actively 
training or engaged in combat operations, either of which makes an ideal test 
bed for a newly delivered product. Action officers should make every effort to 
attend any training exercise utilizing a new system to capture any user 
recommendations and ideas for improvement, or just to gather opinions of the 
value the system offers. A unit in combat will not be as readily accessible as in 
training, but action officers should make and maintain contact with the system 
users to gather valuable operational insight which serves to guide subsequent 
improvements. Also, action officers should strive to meet with units returning 
from operational deployments as soon after their return as possible. Time 
quickly fades memories, both good and bad, and a program office must quickly 
capture any lessons learned relating to the system. 

Additionally, acquisition officers must maintain close ties to the 
organization charged with supporting the system. System support can include 
follow on training, software patches, troubleshooting, help desk support, etc. 
Contractors or another government office such as the Marine Corps Tactical 
Systems Support Activity will likely accomplish these tasks which should include 
analysis of any trends observed in support of the system. This analysis can 
indicate areas implicitly needing improvement and can feed into requirements for 
future increments. 
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All of this gathering of information regarding an operational, fielded 
system wastes time and effort unless the program office applies it through a 
feedback mechanism that fosters continual improvement of both the product and 
the process. One mechanism to accomplish this occurs through reviews of 
future system increments. These reviews must make it a point to consider user 
feedback regarding previous increments and incorporate the most highly valued 
recommendations into future requirements. Such a valid feedback mechanism 
will ensure emphasis on value and continual product improvement, both of which 
will increase the probability of future program successes. 

The process as well as the product in the Sustainment phase 
deserves attention in order to remain relevant and correctly focused. To insure 
the continued quality of the process, an action officer must make an honest, 
introspective analysis of the acquisition process. Some of the obvious questions 
to ask in order to follow the principles of RVEA are: 

• Rapid: Was the process rapid enough to provide value to the user, 
and do future increments meet the user’s required timeline? 

• Value-based: Did the system improve the user’s job, e.g., does the 
user value it? 

• Evolutionary: Does the system readily support upgrades and 
changes? 

The more revealing questions of, “Why?” or, “Why not?” must follow 
these types of yes/no questions. Reflecting back to the discussion of Boyd’s 
OODA Loop, this analysis essentially accomplishes the steps of observe and 
orient. Or using Dr. Hayes-Roth’s more detailed efficient thought model 
(reference Figure 4. ), they equate to observing and assessing the situation. 
The decision loops must not stop there though. To ensure effectiveness, action 
officers must close the loop by deciding upon desired changes; predicting 
outcomes; and selecting, communicating and implementing the best plan of 
action. Furthermore, until the organization either phases out or replaces the 
system, it must repeat and continually validate this cycle in rapid succession. 
Not doing so risks being overcome by the enemy of obsolescence and 
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requirements change, eventually resulting in decreased system value and 
potential program failure. Such honest self-evaluation of the effectiveness of the 
acquisition process will enable a PMO to improve its acquisition process model 
which will produce more viable results in the form of increased user value. 

Many may believe the Sustainment phase comprises the last of the 
acquisition phases and as such, a program office may choose to coast through 
system deployment and support with minimal emphasis on the principles of 
RVEA. In fact though, this phase offers great opportunities to refocus on rapidly 
providing the warfighter valued products, increasing the validity of future 
requirements, and improving the acquisition process. RVEA prescribes those 
very actions, emphasizing the fact that acquisition continues as more of a 
continuous cycle or loop than a process with a beginning and end. Missing 
opportunities for improvement in the Sustainment phase because of lackadaisical 
system support or an end-in-sight PMO attitude not only does a disservice to the 
warfighters, it potentially contributes to the demise of a once viable program. 

The table below summarizes this discussion on the foundation and 
operation of RVEA. Following these acquisition rules of the road will help ensure 
rapid and improving value to the warfighter... measurable program success. 
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DO 

DO NOT 

Identify & prioritize required and related 
attributes and functions. Priority should be 
based on value and time-to-build (difficulty) 

Bite off on too much functionality at once 

Measure availability of valued information 
(A iv ) of each function or service 

Allow a vendor to lock the acquisition into a 
proprietary or inflexible product/process 

Make noticeable improvements in the 
warfighter’s job... if not possible initially, 
then make the system implementation as 
transparent as possible to the user 

Decrease the value of the system by 
unnecessarily taxing the user’s resources 
(time, weight, etc.) 

Inject military specific requirements into 
developing COTS technologies and focus 
on COTS solutions as much as possible 

Prolong service delivery by implementing 
serial development of successive functions 
before providing anything to users 

Develop services in parallel, but start with 
those that offer the biggest bang for the 
buck, and work your way down the 
prioritized list 

Stop looking for improvements once the 
system passes OT&E and begins fielding 

Maintain awareness of and inject military 
requirements/raw technology into COTS 
developments 

Make the users learn a new system 
without providing them value 

Provide something of value to the user in 
less than 2 years after deciding upon a 
technology 

Transition the technology to an acquisition 
program of record until it’s mature 

Continuously look for ways to improve not 
only the product, but the process 

Assume the current acquisition system is 
too constraining or restrictive for RVEA 

Design the system for evolvability 

Be satisfied with the status quo 


Table 2. Dos and Don’ts of RVEA 


D. RVEA OF A USMC TACTICAL SERVICE ORIENTED ARCHITECTURE 

Service oriented architectures have emerged as one of the various 
technical paradigms with great potential to help attain the goals for information 
sharing described in our national strategies (Lewis & Smith, 2007). Enterprise 
SOAs have benefited business entities in the private sector and, if successfully 
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acquired, SOA can also benefit the DoD at not only the enterprise level of the 
military (DoDD 8320.02, 2004), but also the tactical level of warfighting. 

1. What is SOA? 

Referencing Figure 7 below, a generic SOA is a collection of services with 
well-defined interfaces and a standard shared communications model. A service 
usually exists as a discoverable, self-contained software entity that interacts with 
applications and other services through a loosely coupled message-based 
communication model. A service registry enables the discoverability of the 
entities that form services. Services exist as legacy or new software, and 
systems or users subscribe to the functionality provided by these services to 
achieve their purposes. For example, when a service consumer makes a 
reservation through a travel agency website, what appears as a single web- 
based application actually involves the complex orchestration of a set of services 
from various providers. These services could include user authentication, flight 
scheduling, hotel/rental car searches, reservations and credit card validation. 
Through services, SOAs offer the ideal of enabling legacy systems to 
interoperate, presumably without making significant changes (Lewis, Morris, & 
Smith, 2005). 
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Figure 7. Generic Service Oriented Architecture (Lau, 2007) 

This section will first point out some of the specific benefits espoused by 
SOA promoters and then make recommendations for applying the principles of 
RVEA to the acquisition of a Tactical SOA for the USMC. 

Note the purpose of this section is not to wave a SOA flag, perse; rather it 
uses TSOA to illustrate a means to better manage the IT acquisition process 
through RVEA. IT investments should align with the principles of RVEA, and if a 
particular proposed technology contradicts these principles, the acquisition 
should consider another direction. For example, if one technology insists on 
keeping its proprietary nature and as a result does not offer sufficient flexibility to 
meet the demands for continual improvement, the program should investigate 
another possibility. Service oriented architectures run counter to such negative 
attributes as they lend themselves to natural developmental increments and 
openness while offering increasing capabilities in their services. A USMC TSOA 
acquisition program therefore appears more than suitable for the application of 
RVEA principles. 
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2 . 


Benefits of a Tactical SOA 


SOA offers many potential benefits to military applications, but perhaps 
none entice the DoD more than the prospective cost savings and technological 
agility, made possible due to the inherent reusability, flexibility and evolvability of 
SOA through vendor-neutral, open standards. Thomas Erl, acclaimed for his 
expertise on the SOA and the subject’s best-selling author (ThomasErl.com, 
2009), articulates other positives of contemporary SOA: 

Service orientation presents an ideal vision of a world in which 
resources are cleanly partitioned and consistently represented. 

When applied to IT architecture, service-orientation establishes a 
universal model in which automation logic and even business logic 
conform to this vision. This model applies equally to a task, a 
solution, an enterprise, a community, and beyond.... 

The service-orientation ideal has sparked a movement that has 
positioned SOA as the next phase in the evolution of business 
automation. In the same manner in which mainframe systems were 
succeeded by client-server applications, and client-server 
environments then evolved into distributed solutions based on Web 
technologies, the contemporary, Web services-driven SOA is 
succeeding traditional distributed architecture on a global scale. 

All major software manufacturers and vendors are promoting 
support for SOA - some even through direct involvement in the 
development of open standards. As a result, every major 
development platform now officially supports the creation of 
service-oriented solutions. It would appear as though the 
realization of the SOA ideal is well underway. (Erl, 2005, pp. 3-4) 

Table 3 lists some of the many benefits ascribed to SOA. Notice a few of 
these benefits appear performance-oriented, but the majority of them relate to 
the architecture’s inherent flexibility: open, composable, agile, reusable, etc. 
SOA does not lock the implementer into a proprietary stovepipe, and it provides a 
sufficiently open model for disparate architectures to federate more quickly and 
usefully than earlier approaches. These characteristics of SOA and its popularity 
in the private sector indicate the increasing value organizations place on 
adaptability. 
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TSOA Benefits 

(Office of Naval Research, 2008) 

Contemporary SOA Benefits 

(Erl, 2005) 

• Enables speed and flexibility to 
capitalize on new technology and 
business arrangements 

• Reduces time spent to effect 
changes 

• Provides the ability to leverage 
existing technology investments 

• Minimizes the expense and 
complexity of integration 

• Increases reuse 

• Increases tactical agility 

• Increases quality of service 

• Based on open standards 

• Fosters intrinsic interoperability 

• Promotes architectural 
composability 

• Is fundamentally autonomous 

• Supports vendor diversity 

• Promotes organizational agility 

• Fosters inherent reusability 


Table 3. Benefits of SOA 


3. Rapid, Value-Based, Evolutionary Acquisition of a TSOA 

Since government acquisitions cannot realistically hope to “catch up” to 
the innovations of the private sector, the DoD must leverage the current state of 
the art including developments such as SOA to the best of its ability. Case in 
point, the enemy in the Global War on Terror performs netcentric command and 
control via modern mapping, imaging, discovery, and messaging services (etc.) 
available via the World Wide Web. Before the documented SOA benefits will 
ever materialize in the Defense Department, acquisition of a TSOA requires an 
improved process that concentrates on leveraging externally produced value. 
The current acquisition process, which often fails to provide anything of value to 
the warfighter, is causing justifiable apprehension as the USMC investigates 
acquisition of a TSOA. The Marines’ efforts to date toward TSOA include a 
feasibility study conducted by the Office of Naval Research (ONR), part of which 
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included a draft technical description (TD) of the system 10 (Office of Naval 
Research, 2008). This document, although a draft, is thorough and continually 
referenced in this section. As an added benefit, it provides valuable insight into 
the details of TSOA development. Combining the sound technical 
recommendations of the TD with the principles of RVEA—rapid, value-based, 
and continual improvement through an evolutionary loop—will increase the 
chances of the USMC ultimately realizing the benefits SOA offers. 

a. Realizing TSOA’s Potential Value 

SOA adds value to commercial enterprises as pointed out in the 
benefits listed above, but to narrow the focus this section discusses how to 
realize the potential value of Tactical SOA. The tactical aspect of TSOA involves 
making information services available to the lowest tactical level possible, or the 
organizational edge as described by the private sector. The warfighter or edge 
users of TSOA will sense its value initially through improvements in their ability to 
perform currently existing tasks. More importantly though, TSOA will help 
promote future gains in value through its inherent evolvability... assuming an 
acquisition process that concentrates on continual improvement. 

Depending on the first services deployed, TSOA will probably not 
provide any apparently new or revolutionary functionality, but it will allow the 
users to do their job more efficiently and effectively because of easier access to 
and potential filtering of information. Networks supporting the tactical edge must 
address two daunting challenges: the operators require great mobility while, at 
the same time, they must operate with very limited communications bandwidth 
TSOA must therefore embrace concepts such as Valued Information at the Right 
Time (VIRT) to insure against dreaded info-glut and a potentially gridlocked 
network (Hayes-Roth, 2005). TSOA, once deployed, will reduce the number of 


10 The analysis performed for the TD was part of the Advance Fires Coordination 
Technology, Future Naval Capability program, which was sponsored by the Office of Naval 
Research (ONR) under the technical direction of the Naval Surface Warfare Center, Crane IN. 
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specialized systems requiring their own hardware, which will reduce weight and 
power consumption. Additionally, the architecture will provide an open 
framework upon which future technologies and services can build. 

After initial implementation and establishment of the underlying 
framework, TSOA will evolve, incorporating services which will combine to 
provide the same apparent functionality as current stovepipe tactical applications. 
Unlike the legacy applications though, TSOA will ideally enable information 
sharing through semantic interoperability between the services comprising the 
tactical applications. Describing TSOA’s desired end state, it will eventually 
hosts interoperable services for most if not all of the USMC warfighting functions 
of fires, maneuver, intelligence, command and control, logistics, and force 
protection. 

To better illustrate this notion, Table 4 lists some current tactical 
applications, most of which vary greatly in levels of complexity and functionality. 
TLDHS and PFED, for example, have fairly limited application compared to the 
large and complex TBMCS. Each of these applications would subscribe to 
multiple distinct yet reusable services residing on a TSOA. A particular legacy 
application’s functionality and complexity would determine not only how many 
and which services comprise the application, but also their level of reusability 
between applications. For instance, PFED, AFATDS, NFCS and TLDFIS share 
some requirements as target entry devices/applications for the fires chain. Each 
could therefore potentially share a common ‘target recording' service since each 
system would utilize common target attributes such as location and elevation. 
Flowever, each application would require a unique ‘fires request’ service because 
the different firing platforms of artillery, CAS aircraft, and naval gun fire (NGF) all 
have different request formats. This illustrates the concept of common, reusable 
services bundled together with unique services to provide tactical application 
functionality. 
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Advanced Field Artillery Tactical Data System (AFATDS) 

Command and Control Personal Computer (C2PC) 

Joint Automated Deep Operations Coordination System (JADOCS) 

Mobile Electronic Warfare Support System (MEWSS) 

Naval Fire Control System (NFCS) 

Pocket-Sized Forward Entry Device (PFED) 

Target Location, Designation, and Flandoff System (TLDFIS) 

Theater Battle Management Core Systems (TBMCS) 

Web-Enabled Execution Management Capability (WEEMC) 

Table 4. Some Tactical USMC Applications 

Although the TD does not imply that the fires chain should take first 
precedence for inclusion in a TSOA, it studies fires as an example because of its 
stringent requirements for timeliness, correctness, and conciseness. Incidentally, 
because of these attributes and its complexity, the fires chain is also probably 
one of the most difficult warfighting functions to successfully develop and host on 
a TSOA. The program officers, developers, and users should prioritize all 
required services in terms of not only user value but also technical difficulty and 
implement the ones that provide the most value with the least amount of 
difficulty—the so-called low-hanging fruit. After providing rapid initial value, the 
acquisition process must build upon this success to develop increasingly difficult 
or somewhat less valued services. To reiterate the principles of RVEA, the TSOA 
acquisition must not attempt to provide too much functionality in a single step, but 
instead should focus on rapid iterations of valued improvements. 

The TD appropriately recommends both operational and technical 
metrics, including latency, reliability, interoperability, and flexibility, among others. 
However, one measure of value the TD overlooked includes a metric of 
information value, such as the aforementioned A iv , which compares the number 
of bits that actually provide value to the total bits transmitted. For instance, in the 
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fires chain such valued information includes the bits that positively contribute to 
ultimate target prosecution, such as those defining a target’s location, elevation, 
etc. This illustrates the fact that a service’s value comes from (1) delivering 
information that enhances the warfighter’s mission accomplishment, and (2) 
avoiding distracting the warfighter with insignificant information. TSOA must 
measure and guarantee value of the information flowing over the network using 
metrics such as A iv . 

The commercial IT market has much to offer the DoD; 
unfortunately, however, most COTS technologies do not meet some of the most 
stringent government requirements for Information Assurance, with respect to 
authentication, non-repudiation, confidentiality, integrity, or information availability 
(DoDI 8500.2, 2003). The TD points out that SOA technology is not at the level 
of maturity required for a simple COTS purchase of a Tactical SOA. It outlines 
three options for increasing the maturity of TSOA and then recommends one 
option in which the USMC takes the lead in adapting enterprise SOA to create 
TSOA. Another viable option for developing and steering COTS technologies 
being studied by the W2COG smartly leverages the commercial market to better 
address specific military and government requirements. This option explores an 
hypothesis which states that if the government 

(1) continuously develops and furnishes critical raw technology to 
the industrial base; and (2) simply publishes its use cases, 
objective selection criteria, and COTS competitive procurement 
budget in lieu of formal Engineering Development Model-type 
solicitations; then continuing industrial competition will generate 
pure COTS offerings that are ever more aligned with government 
requirements. (Gunderson & Minton, 2009) 
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Raw technology in the case of a 2008 W2COG demonstration 11 included security 
services such as authentication and authorization for web services. After the 
interoperability trial, the W2COG exhibited the viability of the above hypothesis 
by demonstrating the streamlined procurement of a substantial and supportable 
network capability upgrade. This same approach deserves application in 
conjunction with RVEA to the acquisition of TSOA to enable additional value. 

b. Rapidity and TSOA 

To avoid a prolonged development period that risks being 
superseded by changing requirements and technology obsolescence, TSOA 
should not transition to an acquisition program of record now, considering its low 
level of maturity. Instead, it should remain under the cognizance of S&T 
organizations such as ONR while the Marine Corps and other interested entities 
inject their requirements into the maturation process. 

Furthermore, as mentioned, the tactical edge involves operations 
using limited bandwidth. Much of a TSOA’s connectivity depends on overcoming 
or adapting to this limitation through related acquisition programs such as the 
Joint Tactical Radio System (JTRS). JTRS will potentially serve as an enabler 
for improved network operations including TSOA, and it will most likely deploy to 
the lower tactical levels no sooner than about 2015 (Office of Naval Research, 
2008). The TSOA effort should synchronize with these enabling technologies 
and ensure sufficient preparation to establish its underlying framework along with 
basic valued services upon their deployment. This does not imply that TSOA 
should wait for JTRS fielding, rather that TSOA should continue to develop in 
parallel with its enabling technologies. Parallel development would require 
increased agility such as through building on a commercial communication suite 
comparable to JTRS while planning for eventual transition to a tactical system. 

11 Coalition Warrior Interoperability Demonstration 2008, Interoperability Trial (IT) #5.64 
“Trusted Enterprise Service Bus” (T-ESB) demonstrates a potentially quantum improvement in 
the government procurement model for information systems. Joint Interoperability Test Command 
(JITC) sponsored the World Wide Consortium for the Grid (W2COG) Institute (Wl) to conduct IT 
5.64. 
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Once realized, the basic TSOA should develop and incorporate additional tactical 
services rapidly, continuously capitalizing on lessons learned from previously 
deployed services to expand its capability and value. Throughout this iterative 
process, the Marine Corps must maintain keen awareness of developments in 
the SOA industry as well as the military’s S&T centers. Additionally, as 
mentioned above, the program office must constantly evaluate and prioritize 
candidate tactical services based upon their value and difficulty. This process of 
reassessing and retargeting against a moving target will help ensure rapid 
delivery of TSOA value. 

Although realization of TSOA in six years does not seem “rapid,” 
this recommendation is consistent with the principles of RVEA. Considering the 
rate of change of technology, six years equates to about three technology 
generations, during which new discoveries and innovations will occur and 
requirements will change. The USMC should allow technologies to go where 
they may and attempt to steer or leverage their direction by feeding military- 
specific requirements and interests to industry, instead of setting its sights on a 
target six years in the future. Additionally, the USMC must consider the schedule 
risks of TSOA’s enabling technologies, such as JTRS, that do not necessarily 
subscribe to RVEA principles. Any slippage of one of these programs induces a 
proportional delay in TSOA. 

c. Continual Improvement of TSOA 

TSOA and its associated acquisition program intuitively support 
continual improvement because of a natural divisibility into incremental service 
acquisitions. Additionally, the architecture’s inherent beneficial attributes such as 
reusability and modularity could logically play a part in the program’s efforts 
toward improvement. One could even say SOA helps enable continual 
improvement because of its intended basis on open standards that (1) do not 
lock the DoD customer into a single, proprietary solution, and (2) offer flexibility to 
change vendors midstream if the acquisition process requires it. However, these 
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benefits will not happen automatically and without effort from those in charge. 
The program office must continue to focus on the principles of RVEA in order to 
realize the benefits of TSOA. 

Continual improvement of a TSOA product requires rapid iterations 
of increasingly valued capabilities. The underlying open framework of TSOA will 
not provide immediate value to the user by itself. TSOA’s value will come from 
the valued services developed for and available to the warfighter, which reside 
on the framework. For example, the basic functionality of TSOA must include 
authentication and authorization services with the implementation of the 
framework. But TSOA and these services alone provide no apparent functional 
value for an operator. Instead, the value will arrive in the form of useful 
operational services discoverable to the operator. For this reason, the value of 
TSOA hinges on the rapid development, implementation and continual 
improvement of tactical services residing on the underlying framework. 

A PMO must consistently evaluate its internal processes and 
feedback mechanisms to help guarantee continual improvement of the TSOA 
acquisition process. The program office must keep a finger on the pulse of 
COTS IT to ensure continued awareness of commercial best 
practices/technologies. Likewise, the government must also inform the 
commercial IT industry of government interests, requirements and raw 
technologies. Such shared awareness will allow government IT acquisition to 
better leverage the COTS IT vector which will ultimately increase the supply of 
potentially viable products and TSOA services to meet tactical military needs. 
These efforts will help a TSOA program effectively keep up with Moore’s Law 
instead of being beaten by it. The USMC and DoD must manage IT acquisition, 
especially COTS, in such a manner as to enable and not hinder its tactical 
objectives, to include information superiority to the tactical edge through TSOA. 

As the last point for continual improvement during TSOA’s 

acquisition, the USMC must not put all of its proverbial eggs in a single TSOA 

basket, inextricably tying itself to a technology that could end up dying on the 
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vine. Future innovations may lie right around the corner and could render SOA 
obsolete in its attempt to reach the tactical edge. A TSOA acquisition program 
must be ready, willing and able to retarget on a new technology if necessary. 
Staying in touch with commercial developments means maintaining an 
awareness of not only the world of SOA, but also any other potential COTS 
solutions that could benefit the organizational edge. Technologies or protocols 
just beyond the near future of IPv6 and fourth generation wireless could 
potentially leave SOA obsolete by providing superior remote, edge access to 
network services and functions. Program offices must write acquisition strategies 
and their associated contracts in a manner to allow such direction change, and 
RVEA demands short cycle times to allow continual improvement and refocusing 
on not-so-distant targets. A new target could mean writing off TSOA sunk costs 
and killing the program if it would benefit the warfighter. After all, sometimes 
benefit comes in the form of not fielding a new system. 


68 



IV. SUMMARY 


A. CONCLUSION 

Cost overruns, schedule delays, and performance shortfalls have plagued 
defense IT acquisition projects since the acronym IT came into existence, and 
they continue to do so today. One can attribute at least part of this crisis to a 
lack of a clear definition of program success. In its most simple form, program 
success means providing the customers something they value; likewise, 
providing no value to users signals program failure. Even though they have 
worthy intent, without such a clearly defined goal, acquisition commands will 
continue to deliver users their best attempt at a solution and often still fail to 
satisfy operational needs. General blame for such failure traces back to either a 
shortfall of the system itself or a lack of timeliness of acquisition and fielding. A 
late system can easily mean an ineffective system that lacks user value because 
of requirements change or technology obsolescence. These points succinctly 
answer two of the secondary research questions proposed at the beginning of 
this thesis: (1) What defines acquisition project success and failure, and what 
causes a project’s failure? (2) How does the concept of timeliness fit into the 
equation for acquisition value? 

As a potential solution to many of these problems, RVEA focuses on three 
primary factors that can help improve the Defense acquisition process: rapidity, 
user-defined value, and continual improvement through system and process 
evolution. These factors answer the primary research question of this thesis: 
What essential principles enable acquisition programs to deliver valued 
capabilities successfully to the warfighter? 

The value basis of RVEA stems from user involvement in the acquisition 
process from the cradle to the grave. In order to provide value to the IT system 
user, or the warfighter, acquisition programs must identify and understand 
exactly what the user values. Even though broad requirements trickle down from 
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upper-level DoD leadership, a program office must intimately understand user- 
defined value through proactively seeking and maintaining user involvement in 
the process... admittedly not an easy task. Despite their taxing operational 
commitments, the voice of the warfighters who will experience the acquisition 
product hands-on must consistently resound through system design, 
development, testing, manufacturing, fielding, and sustainment. Such 
involvement ensures the system will meet the users’ expectations for not only the 
typical quality metrics such as usability, reliability, and supportability, but also the 
timeliness of the acquisition. The risk of not doing so spells ultimate program 
failure due to an irrelevant and unvalued product. 

Rapidity and Defense Acquisition used in the same sentence regrettably 
has the ring of an oxymoron. If the DoD hopes to field relevant, operationally 
effective and suitable systems, the acquisition process’s speed must increase 
significantly. The current process often fields outdated products because IT— 
and incidentally its associated obsolescence—pervades most systems charged 
with supporting the USMC’s six warfighting functions. The rate of obsolescence 
outpaces the current speed of acquisitions partly due to acquisition programs 
attempting to provide too much functionality in a single step. Considering the 
current pace of innovation and technological advancement, procurements should 
concentrate on selecting the least difficult and highest value solutions currently 
available, which often materialize as COTS. The least difficult solution implies 
one readily available, mature, and proven in a relevant environment if at all 
possible. Accepting anything less can easily lead to schedule delays resulting 
from a prolonged development phase... quite the opposite of rapid acquisition, 
and a glaring opportunity for the enemy, obsolescence. Warfighters expect 
current, useful technology and abhor outdated and consequently unnecessary 
equipment. By focusing on rapidity—providing small yet high value 
improvements to the warfighter in rapid succession—a program increases its 
chances of success. 
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The aspect of continual improvement in the context of RVEA means 
methodically evaluating past accomplishments and failures, both in product and 
process, and applying lessons learned from these evaluations to future actions. 
This ongoing process requires rapid iterations of a recognized, formal feedback 
mechanism using appropriate value metrics, as well as a focus on quick 
solutions. Future solutions or targets should remain as near in the future as 
possible since distant targets (requirements) move unpredictably and often. 
Quantifying “near” as it relates to IT suggests delivering an improvement within 
two years of deciding upon a technology. Continual improvement demands 
subsequent evaluation of the solution’s results and rapid application to not only 
current and future products, but the processes of acquiring and supporting them 
as well. Such rapid, short term retargeting will help decrease the number of 
programs that miss their mark due to aiming at much too distant targets. 
Additionally, in order to increase the number of options available as potential 
acquisition solutions, the DoD must inject its interests, concerns and 
requirements into the mainstream COTS marketplace. As militarily useful COTS 
products become available, the acquisition process must apply the process of 
continual improvement to them, promoting and capitalizing on the ones that work 
and discarding the ones that do not. 

A tactical service oriented architecture offers the USMC value in its 
supposed flexibility and potential long-term cost savings. Additionally, once in 
place, it offers increased technical agility and decreased development time of 
future tactical services and applications. These attributes align with and 
positively support the principles of RVEA, and TSOA is therefore well suited for 
the application of RVEA. 

Figure 8 provides a diagram to help summarize the answer to the 
remaining secondary research question of this thesis that asks how the USMC 
should exploit the principles of rapid, value-based, evolutionary acquisition for the 
development and procurement of a TSOA? RVEA and TSOA’s acquisition first 
require relevant demonstration of the maturity and value of the technology by the 

71 



S&T community. This must include proving the readiness of not only the 
underlying SOA framework and the most basic required services, but also the 
highest priority tactical service(s) offering the greatest “bang-for-the-buck.” Only 
after successful demonstration should the technology then transition to an 
acquisition program of record, aiming to provide the highest value, least difficult 
services to the warfighter in less than two years. Once established as an 
acquisition program, rapidity will help ensure victory over the enemies of 
obsolescence and requirements change. Throughout the process, the program 
office as well as the S&T community must constantly engage user 
representatives to ensure the requirements, current system design, and future 
increments remain valid. Meanwhile, the next iteration of the entire process 
should already be underway, focusing on improvement and having adjusted its 
aim onto not-so-distant targets according to the inputs of a formal, methodical 
and continuous feedback mechanism originating from user-defined value. Such 
an acquisition process would increase the likelihood of success of most IT 
acquisition programs, especially a TSOA. In summary, TSOA holds potential 
benefit for the Marine Corps, but only if we develop and procure it using 
principles such as those embraced by RVEA. 
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B. RECOMMENDED FUTURE RESEARCH 


The research for this thesis and its subsequent writing uncovered some 
areas for future work which might prove useful to the DoD. 

1. PPBES and RVEA 

The DAS has undergone many changes over the past two decades in 
response to the arrival of the information age. The system has adapted in an 
attempt to meet the challenges associated with acquiring increasingly 
sophisticated equipment and capabilities. The PPBE system, however, has not 
sufficiently changed to meet these challenges and has become a hindrance to 
the progress of acquisition. While RVEA stresses speed, flexibility and 
efficiency, the PPBES does not, and the two therefore appear ill-suited for each 
other. Research and recommendations to increase the PPBES’s rapidity and 
responsiveness for acquisition programs would greatly benefit the field of 
Defense IT acquisitions. This, however, is no small undertaking and would most 
likely involve statutory and regulatory changes. Assuming the federal 
government will someday revamp the PPBES, this research could prove valuable 
as a precursor to such an effort. 

2. Cost-Benefit Analysis of USMC SOA 

Trying to capture quantifiable costs and benefits presents difficult 
challenges, at best, in the public domain where emphasis is not on profit. 
Analysts can measure some costs directly but other distantly related and 
sometimes expensive side-effects evade even the best cost analysts. Benefits 
present an even great measurement challenge, especially in the military, due to 
the fact that, for example, sometimes benefit lies in the number of lives or limbs 
saved... a metric nearly impossible to apply a dollar figure to. A cost-benefit 
analysis of a USMC SOA would therefore be a challenging, yet valuable, thesis 
opportunity. Such an analysis could involve either a TSOA or a more 
administratively focused enterprise SOA. The comparison could measure time 

saved by the user, accuracy of data, and personnel metrics, to name a few. 
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3. Establishing a Formal Beta-Test Community 

As this thesis points out, user involvement in the acquisition process helps 
define system value and contributes to program success. Such user 
involvement, though, is often extremely difficult and expensive to coordinate due 
to the time-constrained schedules of the user community. Operational 
commitments, both in continental U.S. training and overseas combat, tax tactical 
system users sometimes to a point of 16+ hour days, 7 days a week. A formally 
established tactical beta-test community of users could help alleviate this 
problem. This community could stand up as a mini-battalion, for example, with a 
sampling of various combat arms MOSs. Assignment to this unit would require 
the Marines to have recent operational experience in their MOS, and they would 
serve there for a minimum of two years. The unit would provide system testers 
and user representatives as dedicated direct support to the acquisition 
community. The recommended research could investigate the feasibility of 
establishing such a beta-test unit and complete a cost-benefit comparison on it. 
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